Paul Moore wrote: > 2009/7/15 Tarek Ziadé <ziade.tarek at gmail.com>: > >> On Tue, Jul 14, 2009 at 2:12 AM, Sridhar >> Ratnakumar<sridharr at 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 at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > -- http://www.ironpythoninaction.com/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4