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 functionality and
>>
>>> 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 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.