Launchpad Bug Tracker schrieb:
> You have been subscribed to a public bug:
>
> Binary package hint: python-debian
why is this report filed for such a non-existing package? If I want to report
something to upstream python, I normally use the python bug tracker as well, not
a random bug tracker at SF.
> /usr/bin/python incorrectly adds /usr/local/lib/pythonX.Y to sys.path
> though a modification of site.py from the standard Python source
> distribution. I'm told this is a Debian convention that Ubuntu simply
> inherits. The reason this is a bug is because a default from-source
> installation of Python by default installs to /usr/local/bin/python, and
> /that/ python has /usr/local/lib/pythonX.Y on its sys.path. What this
> means is that if someone uses the standard from-source build
> instructions (i.e. configure; make; make install) they have the
> potential to break the system python, and thus essentially break their
> operating system.
>
> The problem can be traced to the hack in site.py, where
> addsitepackages() was changed to put sys.exec_prefix/'local' on sys.path
> instead of sys.exec_prefix as is the standard in the source distro of
> python. The reason this is a bug is because of this use case. Let's
> say I'm a Python developer or I'm developing an application that needs a
> cutting edge version of some Python library such as pygtk. I can't use
> the system's pygtk for some reason so I do what is S.O.P on all other
> *nix machines. I download the source distro of python, build and
> install it using the standard commands, then I install the bleeding edge
> pygtk into this python's site-packages. Oops, I've now potentially just
> broken the system python despite my caution!
>
> I have two specific recommendations. First, do not modify site.py;
> revert this back to the exactly what comes from the Python source
> distro. There is already a perfectly valid hook for site customization:
> create a sitecustomize.py module and do any distro based path hacking
> there.
no, this doesn't work, because you have to use site.addsitedir to add additional
packages. importing site from sitecustomize, plus having setuptools' site.py in
the path looks like a real hack.
> Second, in sitecustomize.py, do not put
> sys.exec_prefix/local/lib/pythonX.Y on sys.path. I've been told that it
> is a Debian/Ubuntu feature that packages can be installed in /usr/local
> and automatically made visible in the system tools (this policy applies
> to other applications, not just Python). If that is the case, then
> /usr/bin/python should use a path that does not conflict with a default
> from-source build of Python. I recommend /usr/local/python or
> /usr/local/share/python. Either path would work fine with distutils or
> setuptools based installations (the new standard in Python package
> installations). So, in sitecustomize, you should add
> /usr/local/python/libX.Y or whatever you agree on, on sys.path and you
> will get exactly the same functionality you want without conflicts with
> a source-build.
/usr/local/share/python is not appropriate. I'll see if /usr/local/python/libX.Y
is compliant to Debian guidelines. For upgrade reasons, we should have both
paths checked at least for one release; I'll try to do that for hardy, but it's
short before beta...
> For further safety, I would protect this sys.path
> hacking with an environment variable, e.g. something like this:
>
> import os
> import sys
>
> if not os.environ.get('DISABLE_USR_LOCAL_PYTHON'):
> sys.path.insert(0, '/usr/local/python/libX.Y') # where X.Y is properly
> calculated
>
> Simple, short and sweet. Accomplishes the Debian/Ubuntu goals but
> doesn't harm Python developers.
except that we don't rely on environment variables in packages, so this is not
an option.
--
sys.path incorrectly munged in site.py
https://bugs.launchpad.net/bugs/139140
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
