On 03Jul2016 1556, Terry Reedy wrote:
On 7/3/2016 4:22 PM, Brett Cannon wrote:
So if we really wanted to go this route of breaking out the stdlib, I
think we have two options. One is to have the cpython repo represent the
CPython interpreter and then have a separate stdlib repo. The other
option is to still have cpython represent the interpreter but then each
stdlib module have their own repository.
Option 3 is something in between: groups of stdlib modules in their own
repository. An obvious example: a gui group with _tkinter, tkinter,
idlelib, turtle, turtledemo, and their doc files. Having 100s of
repositories would not work well with with TortoiseHg.
A rough count of how I'd break up the current 3.5 Lib folder (which I
happened to have handy) suggests no more than 50 repos. But there'd be
no need to have all of them checked out just to build - only the ones
you want to modify. And in that case, you'd probably have a stable
Python to work against the separate package repo and wouldn't need to
clone the core one. (I'm envisioning a build process that generates
wheels from online sources and caches them. So updating the stdlib wheel
cache would be part of the build process, but then the local wheels are
used to install.)
I personally would only have about 5 repos cloned on any of my dev
machines (core, ctypes, distutils, possibly tkinter, ssl), as I rarely
touch any other packages. (Having those separate from core is mostly for
the versioning benefits - I doubt we could ever release Python without
them, but it'd be great to be able to update distutils, ctypes or ssl in
place with a simple pip/package mgr command.)
Cheers,
Steve
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
