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

Tres Seaver tseaver at palladion.com
Wed Jul 22 16:26:59 CEST 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Lyon wrote:
> On Tue, 21 Jul 2009 13:41:41 -0400, Tres Seaver <tseaver at palladion.com>
> wrote:

>> Consider the case where the user has built a separate python (e.g., to
>> avoid conflicting with the OS version) in /opt/PythonX.y:  are you
>> actually saying that distutils / setuptools should somehow know the
>> difference betweeen /usr/lib/pythonX.y/site-packages and
>> /opt/PythonX.Y/lib/pythonX.Y/site-packages?  
> 
> It already does.
> 
> If you run the python in /opt/pythonX.X you'll get a different value
> for sys.path than when you run the other python from /usr/lib/pythonX.X.
> 
> Try it and see for yourself..

You missed my point:  I know that sys.prefix etc. is set based on the
location of the executable.  You were complaining that setuptools /
distutils wants to put files in an "OS-controlled directory":  I was
asking how Python was supposed to know the difference between
/usr/lib/python2.x/site-packages (presumably "OS-controlled") and
/opt/Python2.x/lib/python2.x/site-packages (definitely not "OS-controlled").

The solution is to avoid doing distutils / setuptools operations as
root, *ever*, and instead use either an alternate install location (such
as /opt/Python2.x) or use something like virtualenv, which provides a
"safe" sandbox for installing stuff.

> That's because sys.path is calculated relatively within site.py
> depending on where the interpretor is run from.
> 
>> Or are you asserting that
>> it is somehow invalid for distutils / setuptools to install things into
>> /opt/PythonX.Y/lib/pythonX.y/site-packages, which is certainly not an
>> "OS controlled directory."
> 
> Not at all.
> 
> All I'm saying is that after so many years of python under linux and
> operating system we should have observed the common use cases and
> learned a thing or two.
> 
> If you hadn't noticed, there is mayhem in package installation because
> the operating system tries to install its packages in the same place
> as setuptools does in development mode.
> 
> That has got to be asking for trouble..

Users who install anything into /usr/lib/python2.x in "development" mode
has already invited all the trouble they can handle into the house.

> When I go into python on ubuntu I see there is /usr/local/pythonX.X/lib/
> site-packages and I'm wondering why the hubba setuptools/distutils
> doesn't put packages there by default. That would solve a lot of
> problems.
> 
> Just leave /usr/lib/pythonX.X//lib/site-packages to the O/S.
> 
> Wrapping up.. most of the functionality that I'm asking for is
> already there. So I don't require anything extra. I don't want
> things taken out.
> 
> All I'm suggesting is that we use what we already have a bit smarter.

That is precisely how I think of virtualenv: it sits on top of distutils
/ setuptools, and makes it sane to do Python development without
compromising the core system.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKZyGz+gerLs4ltQ4RAupxAJ95RZQJm6t1FtcFY+DMyHHmwRjmSACglo+W
TehyHzxUwHQ5LfdibJsgUcA=
=nf13
-----END PGP SIGNATURE-----



More information about the Python-Dev mailing list