Paul Moore wrote:
2009/7/15 Tarek Ziadé <ziade.tarek@gmail.com>:
On Tue, Jul 14, 2009 at 2:12 AM, Sridhar Ratnakumar<sridharr@activestate.com> wrote:
Here are my comments regarding PEP 376 with respect to PyPM (the Python package manager being developd at ActiveState)
Multiple versions: I understand that the PEP does not support installation (thus uninstallation) of multiple versions of the same package. Should this be explicitly mentioned in the PEP -- as `get_distribution` API accepts only `name` argument, and not a `version` argument?
That's another can of worms ;)
:-)
Before I answer here's a bit of background, i's a bit long but required, sorry
For people that don't want to read the rest, here's the idea : multiple version support imho should be introduced later, if they are to be introduced, by extending PEP 302 protocol.
Disclaimer: I've only read the short version, so if some of this is covered in the longer explanation, I apologise now.
-1.
I agree. People with versioning issues *should* be using virtualenv. Michael Foord
In my view, multiple version support is not at all related to PEP 302 - or to core Python in general. The import statement has no concept of versions, any version handling is done by explicit user manipulation of sys.path.
PEP 302 is currently purely an import protocol. As such, it only cares about locating the correct code to run to populate sys.modules['foo']. Once the code has been located, there are a number of other details that might be useful, hence the extensions like get_data, get_filename, etc. But note that these are all *loader* extensions - their starting point is an imported module.
The PEP 376 support I've just added is a *finder* extension, which is working alongside the scanning of the container - but rather than looking for modules, it's looking for distributions. Disappointingly (for me) it turned out not to give much opportunity to share code - the finder extensions could just as easily have been a completely independent protocol.
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.
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. 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...
Paul. _______________________________________________ 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/fuzzyman%40voidspace.org.u...