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

[Paul Moore]

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.

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.