[Python-Dev] release cadence

Steve Dower steve.dower at python.org
Tue Jul 5 13:38:21 EDT 2016

On 05Jul2016 1028, Barry Warsaw wrote:
> On Jul 03, 2016, at 04:21 PM, Steve Dower wrote:
>> 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.
> A concern with a highly split stdlib is local testing.  I'm not worried about
> pull request testing, or after-the-fact buildbot testing since I'd have to
> assume that we'd make sure the fully integrated sumo package was tested in
> both environments.
> But what about local testing?  Let's say you change something in one module
> that causes a regression in a different module in a different repo.  If you've
> only got a small subset checked out, you might never notice that before you
> PR'd your change.  And then once the test fails, how easy will it be for you
> to recreate the tested environment locally so that you could debug your
> regression?
> I'm sure it's doable, but let's not lose sight of that if this path is taken.

My hope is that it would be essentially a "pip freeze"/"pip install -r 
..." (or equivalent with whatever tool is used/created for managing the 
stdlib). Perhaps using VCS URIs rather than version numbers?

That is, the test run would dump a list of exactly which stdlib versions 
it's using, so that when you review the results it is possible to 
recreate it.

But the point is well taken. I'm very hesitant about splitting out 
packages that are common dependencies of other parts of the stdlib, but 
there are plenty of leaf nodes in there too. Creating a complex 
dependency graph would be a disaster.


> (Personally, I'm +0 on splitting out the stdlib and -1 on micro-splitting it.)
> Cheers,
> -Barry

More information about the Python-Dev mailing list