On Tue, Mar 11, 2008 at 09:45:21AM -0400, Barry Warsaw wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mar 11, 2008, at 3:43 AM, Matthias Klose wrote:
>
>> Currently Debian's python has /usr/local/lib/python2.x/site-packages
>> in sys.path allowing for installation of local modules. Barry did
>> point out that this conflicts with a python installation, where
>> /usr/local is the default prefix, and the system python gets modules
>> from the local installation. Some suggestions were made to fix this:
>>
>> - add an env var to not include /usr/local/lib/python2.x/site-packages
>> when the env var is set. Keeps standard behaviour without
>> modifications and allows people to remove it from sys.path. But
>> requires the user to know about that option.
>>
>> - add another path (e.g. /usr/local/python/lib2.x/site-packages),
>> and remove the /usr/local/lib/python2.x/site-packages path after
>> the next release. Does provide an upgrade path, but doesn't solve
>> the probem immediately.
>
> Thanks for raising this issue Matthias. There are a couple of other
> points I'd like to make.
>
> This isn't /just/ a problem for Python experts or developers. Sometimes
> we recommend that Ordinary Users install Python from source, say to use
> an application that isn't supported by a distro's packaging system.
> There can be lots of reasons for this: maybe the app is in beta testing,
> maybe they want to try things out without affecting the system version,
> etc.
>
> Python developers may not be Debian experts and may not know about this
> system peculiarity. So when we tell people "just do configure; make;
> make install" we can actually do inadvertent damage to their Debian
> system.
Problem is that both are very natural, having local packages being
picked up by the system python in
/usr/local/lib/python2.X/site-packages as well as being able to
install a new python with a prefix of /usr/local.
Given this choice I'd prefer the second option as well, it seems more
natural then the first and an upgrade path is important (Wichert's
argument about the first having problems with su is also important).
It would be good if the distutils could be changed to install local
packages there by default then, so as to provide the least surprises:
just "python setup.py install" as root would do the correct thing.
When looking at the grand scale of things the change for the system
Python to look for local packages in
/usr/local/python/lib2.X/site-packages (or
/usr/local/python/site-packages2.X?[1]) is probably best done upstream
so it is on all systems the same. The build system could do this when
a prefix of /usr is passed to configure.
This can not be done by using a system wide configuration file IIRC,
since the Python make system will pick up those configuration files
hence breaking the /usr/local install again as well as generating
FTBFS on systems that have python already installed during the
build[0]. This is possibly a bug in the Python make system though,
what is the rationale for picking up the distutils configuration files
for building python itself? Surely all this info is passed to
configure?
> What confuses me is that this doesn't appear to be a convenience based
> on permissions,
It has nothing to do with permissions. The sysadmin should never
install things into /usr/ directly, /usr/local/ is their playground.
> I'm also uncomfortable with the way that Debian accomplishes this: it
> hacks Python's standard site.py. There really should be a better way to
> do this (I have to think about this a bit though).
In the python we ship to our customers (living in /opt/vendor/python2X
as per FHS) we place a .pth file in the site-packages directory to
accomplish extra locations on sys.path (pointing somewhere else in our
/opt/vendor hierarchy). Maybe
/usr/lib/python2.X/site-packages/debian.pth would be a better way to
handle this on Debian? Or are there reasons not to do this? Although
the suggestion I make above, changing it upstream, would make this
unnecessary.
[As an aside, I find what happens with python-support much worse. I
regularly waste time re-discovering that a whole load of system
installed packages can't be found in /usr/lib/python2.X/site-packages/
but live somewhere in /var/lib/python-support/. It's a violation of
the FHS as well, /var/lib/ is for program state information, .pyc's
are not state).]
Regards
Floris
[0] This has bitten me in the past with FTBFS when having a
~/.pydistutils.cfg defining a `home=~' and trying to rebuild the
Debian Python package. I think it also happens when trying to
build a new upstream python with an existing distutils
configuration somewhere.
[1] Both violate FHS though. The directories allowed in /usr/local
after a fresh install are limited
(http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY).
But /usr/local/lib/python/site-packages2.X does seem a little
cumbersome and confusing (since a local python will use
/usr/local/lib/python2.X/site-packages). Maybe a
/usr/local/lib/system-python/ structure would work, but that is
getting cumbersome again.
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
