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.
Cheers,
Steve
(Personally, I'm +0 on splitting out the stdlib and -1 on micro-splitting it.)
Cheers,
-Barry
_______________________________________________
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
