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