On Wed, Jul 15, 2009 at 11:00 PM, Tarek Ziadé<ziade.ta...@gmail.com> wrote: > On Wed, Jul 15, 2009 at 12:10 PM, Paul Moore<p.f.mo...@gmail.com> wrote: >> >> Disclaimer: I've only read the short version, so if some of this is >> covered in the longer explanation, I apologise now. > > Next time I won't put a short version ;) > > >> >> PEP 376 support has added a requirement for 3 additional methods to >> the existing 1 finder method in PEP 302. That's already a 300% >> increase in complexity. I'm against adding any further complexity to >> PEP 302 - in all honesty, I'd rather move towards PEP 376 defining its >> *own* locator protocol and avoid any extra burden on PEP 302. I'm not >> sure implementers of PEP 302 importers will even provide the current >> PEP 376 extensions. >> >> I propose that before the current prototype is turned into a final >> (spec and) implementation, the PEP 302 extensions are extracted and >> documented as an independent protocol, purely part of PEP 376. (This >> *helps* implementers, as they can write support for, for example, >> eggs, without needing to modify the existing egg importer). I'll >> volunteer to do that work - but I won't start until the latest >> iteration of questions and discussions has settled down and PEP 376 >> has achieved a stable form with the known issues addressed. > > Sure that makes sense. I am all for having these 302 extensions > flipped on PEP 376 > side, then think about the "locator" protocol. > > I am lagging a bit in the discussions, I have 10 messages left to read or so, > but the known issues I've listed so far are about the RECORD file and > absolute paths, > I am waiting for PJE example on the syntax he proposed for prefixes, > on the docutils example. > >> Of course, this is moving more and more towards saying that the design >> of setuptools, with its generic means for locating distributions, etc >> etc, is the right approach. >> We're reinventing the wheel here. But the >> problem is that too many people dislike setuptools as it stands for it >> to gain support. > > I don't think it's about setuptools design. I think it's more likely > to be about the fact > that there's no way in Python to install two different versions of the > same distribution > without "hiding" one from each other, using setuptools, virtualenv or > zc.buildout. > > "installing" a distribution in Python means that its activated > globally, whereas people > need it locally at the application level. > >> My understanding is that the current set of PEPs were >> intended to be a stripped down, more generally acceptable subset of >> setuptools. Let's keep them that way (and omit the complexities of >> multi-version support). >> >> If you want setuptools, you know where to get it... > > Sure, but let's not forget that the multiple-version issue is a global > issue OS packagers > also meet. (setuptools is not the problem) : > > - application Foo uses docutils 0.4 and doesn't work with docutils 0.5 > - application Bar uses docutils 0.5 > > if docutils 0.5 is installed, Foo is broken, unless docutils 0.4 is > shipped with it.
As was stated by Debian packagers on the distutils ML, the problem is that docutils 0.5 breaks packages which work with docutils 0.4 in the first place. http://www.mail-archive.com/distutils-...@python.org/msg05775.html And current hacks to work around lack of explicit version handling for module import is a maintenance burden: http://www.mail-archive.com/distutils-...@python.org/msg05742.html setuptools has given the incentive to use versioning as a workaround for API/ABI compatibility. That's the core problem, and most problems brought by setuptools (sys.path and .pth hacks with the unreliability which ensued) are consequences of this. I don't see how virtualenv solves anything in that regard for deployment issues. I doubt using things like virtualenv will make OS packagers happy. David _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
