[Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from PyPM's point of view]

[Tarek Ziadé]

On Sun, Jul 19, 2009 at 3:08 PM, R. David Murray<rdmurray at bitdance.com> wrote:
> On Sun, 19 Jul 2009 at 16:07, Nick Coghlan wrote:
>>
>> David Lyon wrote:
>>>
>>> So it isn't clear why you want to remove the thing that you are
>>> advocating works so great....
>>
>> Jim was quoting someone *else* that had suggested removing it (I'm not
>> sure how serious the original suggestion actually was though).
>
> It was Tarek, and I'm pretty sure it was in the nature of what
> rhetoricians (among others) call "reductio ad absurdum".  But
> Tarek would have to let us know for sure, since it seems from
> subsequent discussion that the notion is not _completely_ absurd,
> just mostly :)
>

Yes, well, maybe we should go back to Python-ideas to continue this
discussion, :)

What made me say that, is the unecessary complexity of the situation
because we have right now :

"Python the application" v.s. "Applications that uses Python the interpreter"

So we have:

A - a drop-it-in directory were we can put packages and modules

B - installers that adds automatically packages and modules in the
drop-it-in directory

C - applications that uses these installers to install themselves and
their dependencies in the drop-it-in directory.

D - a tool like virtualenv that duplicates a Python installation so
this drop-in-in directory is not shared globally

C - installation documentation that tells you to use virtualenv to
create a custom environment
      so you are sure not to break dependencies. (But you can break
them nevertheless because using virtualenv
      is not enforced :) )

E - OS packagers that installs all distributions in the drop-it-in
directory (or a similar place)


So if you remove the global site-packages, "Python the application"
dissapear in favor of "Python the interpreter",
and people have to point a local, non-shared drop-it-in directory to
run any python application that uses extra modules:

1- For Jim's case, the per-user site packages (PEP 370) can be used
2- For every application it can be a local directory loaded in
sys.path at startup
3- For OS packagers a single directory where they maintain a
collection of packages and modules for their system.

But unfortunately, the problem remains because of (3) : OS packagers
will fight against applications (2) that deal with their own
dependencies to avoid having duplicate packages in their system.

That's why a shared space, not loaded at startup by site.py, that
knows how to handle multiple versions for the same distribution
would be required. Every script (eg application) would decide which
version to use, or use the default version by default.
And a smart PEP 302 loader/importer would get the right versions.

Regards
Tarek