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

[Tarek Ziadé]

On Wed, Jul 15, 2009 at 5:14 PM, Paul Moore<p.f.moore at gmail.com> wrote:
> 2009/7/15 Tarek Ziadé <ziade.tarek at gmail.com>:
>> On Wed, Jul 15, 2009 at 12:17 PM, Michael
>> Foord<fuzzyman at voidspace.org.uk> wrote:
>>>> 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.
>>>
>>
>> Let's remove site-packages from Python then.
>
> If virtualenv/py2exe/cx_Freeze/py2app don't offer a solution, then
> maybe you're right.

They do offer a solution, but these solution are hard to maintain from
a OS packager point of view.

In any case I don't see any use case to have a "site-packages"
remaining in Python itself.

> If standard Python support for multi-version imports is required (it's
> not by me, but I accept that some people want it), then it should be
> designed in thoughout:
> [..]
>
> Any PEP dealing with multi versions should address these issues. It's
> a big area, and I have no interest in it myself, but I do have an
> interest in avoiding partial solutions which only look at some of the
> questions that might arise.
>
> Look - I really, really don't mind if people use setuptools. Honest.
> But I do mind if core python gets changed to support little bits of
> what setuptools does, adding complexity to deal with issues that
> setuptools handles, but without making it possible to avoid using
> setuptools. Where's the benefit to anyone then?

I totally agree. But I think that the boundary between what Python+stdlib
should provide feature-wise and what third party packages provides is
still fuzzy and should
be made clearer.

At some point, third party projects are trying hard to isolate dependencies
because they can't do it with the execution environment Python sets by
default when
you launch a script or an interpreter.

site.py loads site-packages and user site-packages at startup
basically, and you can
use PYTHONPATH / sys.path to add more, but that's partially shared by all apps.

To address this issued, a project like zc.buildout will create a local
repository of distributions, and will
change sys.path on the fly so the local repository is used.

virtualenv on its side creates an isolated Python installation for
your application,

So If the stdlib doesn't provide a standard protocol that goes further
than that,
people that have this need will continue to use zc.buildout or
virtualenv and install many times
the same libs on a system.

It's perfectly fine from an application developer PoV, but it make
site-packages obsoletes and
every application installed that way looks like a black box for os
packagers. They don't want that.

At the end, application developers have to care about the way their applications
dependencies are installed, were they should just give the list of
those dependencies,
and let any package manager project install them.

If these matters are not adressed by Python sdtlib, then we should
remove the loading of
site-packages at Python startup completely, and make it cristal clear
that it's not the core/stdlib
problem.

Otherwise we should think hard about how to let os packagers manage a
single repository
of Python distributions (and multiple versions) and how application
developers could use them from within
their applications. This protocol imho could be in the sdtlib even if
the implementation
is outside, but that's just me.

In any case, these issues can be postponed after PEP 376, because
that's a another (bigger) part of the puzzle.

Regards
Tarek