[Distutils] Q about best practices now (or near future)

Nick Coghlan ncoghlan at gmail.com
Fri Jul 19 06:23:09 CEST 2013


On 19 July 2013 09:37, Vinay Sajip <vinay_sajip at 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.

It's a real requirement - Linux distros need it to work around
parallel installation of backwards incompatible libraries in the
system Python. Yes, it's an implementation defined feature of
pkg_resources (not setuptools per se), but it's one that works well
enough even if the error message can be opaque and the configuration
can get a little arcane :)

> 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 :-)

I like the idea of switching to zc.buildout style entry points - it
makes it easier to get pip to a point where "no setuptools" means "can
only install from wheel files" rather than "can't install anything"
(that way pip can install setuptools from a wheel if it needs to build
something else from source).

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Distutils-SIG mailing list