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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4