[core-workflow] What would it take to split the stdlib out into its own git repo?

[Nick Coghlan]

On 17 July 2016 at 11:27, Ned Deily <nad at python.org> wrote:
> On Jul 16, 2016, at 20:46, Brett Cannon <brett at python.org> wrote:
>> And are there benefits? My hope/hunch is that if we make the stdlib its own repo then other implementations could include the stdlib as a submodule or something, making it easier for them to not only keep up-to-date with fixes to the stdlib, but also make it easier for them to push changes upstream that everyone would benefit from instead of having any changes silo-ed off in their own repo.
>
> Without giving it a lot of thought, this strikes me as an unnecessary complication.  It will undoubtedly make CPython development more complicated, both initially in separating the stdlib out and, in the long run, figuring out how to keep them in sync all the time.  Other Python implementations already have to deal with this, if they want to, and they can very easily ignore the CPython-specific parts of the repo without having to add all this additional work on everyone.  Let's not make this migration harder than it has to be.  We've got enough to do already.

+1.

Aside from the practical problems with the git separation itself, we
also have the problem of getpath.c already being a tremendously
complicated piece of imperative logic (combining both compile time and
runtime checks, with an entirely separate implementation for Windows),
which would need updating to cope with separation of the standard
library into "the cross-implementation bits" and "the CPython bits".

That said, I'd actually be in favour of doing such a structural split
*within* the repo (similar to the way we separated out the Programs
directory a while back), but even that would be quite a lot of tedious
work for minimal real gain.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia