You may find the comments in #19 interesting 😉 Or maybe not.

Thanks for the note! I think that the submodule approach would be useful, but definitely even one copy of the source tree is almost 70x larger than the frozendict source tree.

The problem with this is the changes in cpython are working against us as far as trying to make a tidy solution. For example, I had to add several new headers that were included by Python.h and others that weren't previously included. And the reverse of that is also true: there are files that are no longer included by Python.h that are still included in this repo.

I'm thinking about throwing together a script that can be run ad-hoc to determine when the headers need to be updated, but that script would need to be able to do some sort of header/include analysis to figure out what needs to be added, so it might not be that simple of a script to write XD

For example, I had to add several new headers that were included by Python.h and others that weren't previously included. And the reverse of that is also true: there are files that are no longer included by Python.h that are still included in this repo.

Sounds like something that rsync ought to be able to handle? Probably makes sense to just copy across the whole headers directory, rather than trying to work out what includes are or aren't used by Python.h ?

True, copying over Objects and Include is only ~5MB.

We could probably drop a VERSION file tracking which patchlevel of the python version we are on in cpython_src, then put a check in setup.py that notifies when there is a newer version available.

Another idea that may be the most elegant: use the submodules, but point it to a fork of cpython that drops all other files other than Objects/* and Include/*, so then the submodule doesn't consume tons of space. Then, that repo can just be rebased whenever there are new python versions.

Are you volunteering to maintain that other fork of cpython? 😆
(also, part of the reason that the "submodule approach" was so huge was that it was also storing full git-history. As I noted in #19 it unfortunately doesn't seem possible to use shallow clones with "branched" submodules)

Excuse me, but this is a delicate part and I did myself here:
000f296

No worries, thanks!

About the fork, sorry, but I will not trust third party sources of such a delicate code. And I see no advantage to have a separate repo instead of simply copying the source I need in this one.