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

[Tarek Ziadé]

On Wed, Jul 15, 2009 at 5:16 PM, Joachim König<him at online.de> wrote:
> Tarek Ziadé wrote:
>>
>> So basically "site-packages" is a distribution location that is
>> avoided by everyone because it doesn't
>> know how to handle multiple versions.
>
> I think you overrate the importance of having multiple versions of a package
> available
> for the same python interpreter. If you have m different versions of n
> packages then
> you could have n**m different combinations for an application so you need a
> possiblilty to select one combination from n**m possible ones at application
> startup time. Is this really worth it?

When you create an application that uses several libs, and when you
create your distribution,
you end up pinning a version for each one of your dependency to avoid
any problems.

While it's workable in a small application to list the dependencies in
a text file, and let your users
install them manually, it's impossible in bigger applications.

Applications based on Zope for example have **hundreds** of dependencies
you need to have installed, in very specific versions.

If you install a Zope 2 app on your system, and a Zope 3 one, you have
good chances of
breaking them because the "zope.schema" distribution is incompatible.

So either each application ships its own collection of dependencies
and ignore site-packages (that's what zope-based
applications does with zc.buildout), either they have a way to pick
the right version of each package.


>
>> If we had a multi-versions
>> support protocol, that would
>> help os packagers and application developers to be friends again imho ;)
>>  Let's remove site-packages from Python then.
>
> The _one_ site-packages folder stands for _one_ python interpreter. All the
> clever
> efforts to provide a set of package versions at runtime to an application
> (that uses
> the singleton python interpreter) do logically create a new python
> interpreter with
> a site-packages folder that contains just the versions of the packages the
> application
> needs, unfortunately by mucking with PYTHONPATH and <package>.pth, site.py
> etc
> making it very difficult to understand what is happening for the joe average
> python developer.

That's what we have nowadays. python packages installed in different places,
and scripts tweaking the path to launch an application with them.