On Thu, Jul 18, 2013 at 8:33 PM, Daniel Holth <dholth@gmail.com> wrote:
On Thu, Jul 18, 2013 at 8:15 PM, Donald Stufft <donald@stufft.io> wrote:
On Jul 18, 2013, at 7:37 PM, Vinay Sajip <vinay_sajip@yahoo.co.uk>
wrote:
I think the point is that people might be dependent on this
changing it out from underneath them could break their world.
I got the point that Daniel made, and my question was about *how* their
world would break, and whether we really need to support multiple versions of something installed side-by-side, with on-the-fly sys.path manipulation. If that is a real requirement which should be supported, shouldn't there be a PEP for it, if it's coming into Python? It's not supported by distutils, and it has been a point of contention.
A PEP would allow standardisation of the multiple-versions feature it
it's considered desirable, rather than definition by implementation (which I understand you're not in favour of, in general).
If it's not considered desirable and doesn't need support, then we only
need to consider if it's undeclared setuptools dependencies that we're concerned with, or some other failure mode not yet identified - hence, my questions. I like to get into specifics :-)
Yes I'm against implementation defined features. However this is already
functionality and the status quo for this particular implementation. Basically I'm worried we are trying to fix too much at once.
One of the major reasons for distutils/packaging failing was it tried to
fix the world in one fell swoop. I see this same pattern starting to happen here. The problem is each solution has a bunch of corner cases and gotchas and the more things we try to fix at once the less eyes we'll have on each individual one and the more rushed the entire toolchain is going to be.
I think it's *really* important we limit the scope of what we fix at any
one time. Right now we have PEP426, PEP440, PEP439, PEP427, Nick is talking about an Sdist 2.0 PEP, Daniel just posted another PEP I haven't looked at yet, this is going to be another PEP. On top of that we have a number of issues related to those PEPs but not specifically part of those PEPs.
A lot of things is being done right now and I personally have having
trouble keeping up and keeping things straight. I know i'm not the only one because I've had a number of participants of these discussions privately tell me that they aren't sure how I'm keeping up (and i'm struggling to do so). I really don't want us to ship a bunch of half baked / not entirely thought through solutions.
So can we please limit our scope? Let's start by fixing the stuff we
have now, punting on fixing some other problems by using the existing tooling and then let's come back to the things we've punted once we've closed the loop on some of these other outstanding things and fix them better.
I feel your pain.
We might as well allow happy setuptools users to continue using setuptools. I don't care about making a pkg_resources console_scripts handler that does the same thing because we can just use the existing one. The more important contribution is to provide an alternative for people who are not happy setuptools users.
Which is an argument, in my mind, to vendor setuptools over bundling (assuming people are using "bundling" as in "install setuptools next to pip or at least install a .pth file to access the vendored version"). Including pip with Python installers is blessing it as the installer, but if we include setuptools as well that would also be blessing setuptools as *the* building tool as well. If people's preference for virtualenv over venv simply because they didn't want to install pip manually has shown us anything is that the lazy path is the used path. If the long-term plan is to bless setuptools then go for the bundling, but if that decision has not been made yet then bundling may be premature if the bundling of pip with Python moves forward.