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

[Tarek Ziadé]

On Wed, Jul 15, 2009 at 12:10 PM, Paul Moore<p.f.moore at gmail.com> wrote:
>
> Disclaimer: I've only read the short version, so if some of this is
> covered in the longer explanation, I apologise now.

Next time I won't put a short version ;)


>
> 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.

Sure that makes sense. I am all for having these 302 extensions
flipped on PEP 376
side, then think about the "locator" protocol.

I am lagging a bit in the discussions, I have 10 messages left to read or so,
but the known issues I've listed so far are about the RECORD file and
absolute paths,
I am waiting for PJE example on the syntax he proposed for prefixes,
on the docutils example.

> 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.

I don't think it's about setuptools design. I think it's more likely
to be about the fact
that there's no way in Python to install two different versions of the
same distribution
without "hiding" one from each other, using setuptools, virtualenv or
zc.buildout.

"installing" a distribution in Python means that its activated
globally, whereas people
need it locally at the application level.

> 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...

Sure, but let's not forget that the multiple-version issue is a global
issue OS packagers
also meet. (setuptools is not the problem) :

- application Foo uses docutils 0.4 and doesn't work with docutils 0.5
- application Bar uses docutils 0.5

if docutils 0.5 is installed, Foo is broken, unless docutils 0.4 is
shipped with it.

So right now application developers must use tools to isolate their
dependencies from
the rest of the system, using virtualenv or zc.buildout, and ship the
dependencies with them.
So they are sure that their applications are not broken by the system.

This is not optimal of course, because you end up with several
occurences of the same
versions sometimes. And can be a nightmare for os packagers and maintainers.

And virtualenv and such tools are now required when you develop
applications (mid-size and large ones)
and the "good practice" is to avoid any installation of any
distributions in Python itself.

So basically "site-packages" is a distribution location that is
avoided by everyone because it doesn't
know how to handle multiple versions. If we had a multi-versions
support protocol, that would
help os packagers and application developers to be friends again imho ;)

Regards
Tarek

-- 
Tarek Ziadé | http://ziade.org