On Wed, Jul 15, 2009 at 12:10 PM, Paul Moore<p.f.moore@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. So right now application developers must use tools to isolate their dependencies from the rest of the system, using virtualenv or zc.buildout, and ship the dependencies with them. So they are sure that their applications are not broken by the system. This is not optimal of course, because you end up with several occurences of the same versions sometimes. And can be a nightmare for os packagers and maintainers. And virtualenv and such tools are now required when you develop applications (mid-size and large ones) and the "good practice" is to avoid any installation of any distributions in Python itself. So basically "site-packages" is a distribution location that is avoided by everyone because it doesn't know how to handle multiple versions. If we had a multi-versions support protocol, that would help os packagers and application developers to be friends again imho ;) Regards Tarek -- Tarek Ziadé | http://ziade.org