[Distutils] [Python-Dev] PEP 376 - from PyPM's point of view

[Michael Foord]

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/