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

[Paul Moore]

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.

For me, py2exe (and a clean virtual machine if I require an absolutely
pristine environment, I guess virtualenv would help here too) does
what I need for application packaging. But I'll freely admit that my
needs are minimal.

Bluntly, as Python stands, import and sys.path do not offer any core
support for multiple versions. Custom solutions can be built on top of
that - that's what setuptools does. But they are precisely that -
custom solutions, and should be supported as such, outside the core
(and stdlib).

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:

- how do I import version 0.7.1 of package foo, rather than 0.7.2?
- how do I use foo 0.8 at my interactive prompt, and import bar 0.2
which relies on foo 0.7.1?
- what happens if I import foo 2.0 (which requires baz 0.1) and bar
1.5 (which requires baz 0.2)?
- what does "import foo" (without a version number) mean? Is it
different if it's at the command line or in bar 0.5 (which explicitly
declares a dependency on foo 0.7 in its setup.py)? Does the answer to
that mean that imports always need to read dependency information?
- does your head hurt yet? I could go on...

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?

Paul.