
At 11:10 AM 7/15/2009 +0100, Paul Moore wrote:
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).
Btw, this is why setuptools chose to implement these things as adapters or generic functions in pkg_resources (and in the vestigial bits that were added to python 2.5's pkgutil).
So as you can see, trying to solve these particular problems tends to lead to reinventing setuptools or at least portions thereof. ;-)
But the problem is that too many people dislike setuptools as it stands for it to gain support. 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).
Even without multi-version support, the parts of PEP 376 that aren't about uninstallation are still reinventing chunks of pkg_resources. Had pkg_resources been in the stdlib a couple years back (note that bugs and changes in it are still quite rare), the PEP 376 bits for pkgutil could have been focused strictly on uninstallation, and just reused pkg_resources API for finding distributions, reading metadata, getting version info, etc. etc.
All that stuff is extremely stable code, very widely used for a very long time. If politics is the only thing keeping it from being used, then that's a pretty sad statement about the community, given that pkg_resources is not to blame for 99% of what people complain about in relation to setuptools. All pkg_resources does is find stuff (on request) and maybe add it to sys.path (on request), pull out data and metadata from distributions (on request), or set up namespace packages (on request).
So if politics demands that it be rejected by association with "setuptools", then just search-and-replace the API, PEP 8-ify it, call it something different, and lie to everyone about where it came from. I won't tell if you won't. ;-)