On 19 July 2013 09:37, Vinay Sajip <vinay_sa...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
