PYTHONUSERBASE should not affect distutils.sysconfig.get_python_lib and friends

[Marien Zwart]

Binary package hint: python2.6

The PYTHONUSERBASE variable sets the base directory for the *user* site directory. This defaults to ~/.local, and sensible values for it will generally include $HOME. This is not very well documented, but see for example http://docs.python.org/whatsnew/2.6.html#pep-370-per-user-site-packages-directory . I like to set PYTHONUSERBASE=$HOME/lib in my ~/.profile for example, so any locally installed packages end up below ~/lib/python2.x, where I can conveniently grep through them and the like.

The dist-packages vs site-packages logic ubuntu adds to distutils checks for the existence of this variable even if it is being asked for the *system* site-packages directory or one in some other explicitly set prefix. This does not make any sense.

For example: a trivial setup.py I wrote for testing (with pretty much modules=['somefile.py'] in it) tries (and fails, I'm not root) to install into /usr/local/lib/python2.6/dist-packages/ without PYTHONUSERBASE set and into /usr/lib/python2.6/site-packages/ with PYTHONUSERBASE=$HOME. This is completely bizarre: PYTHONUSERBASE is only used to modify the location for --user installs by vanilla python, it should not magically affect other packagedir lookups.

ProblemType: Bug
Architecture: i386
Date: Fri Nov 6 00:54:50 2009
DistroRelease: Ubuntu 9.10
Package: python2.6 2.6.4-0ubuntu1
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: python2.6
Uname: Linux 2.6.31-14-generic i686

[Matthias Klose (doko)]

this has nothing to do with dist-packages/site-packages. distutils doesn't honor PYTHONUSERBASE. Use --user for now to install packages.

[Marien Zwart (marienz)]

Distutils does honor PYTHONUSERBASE, but it only does so when using --user (which is what I expect). When I do *not* use --user whether PYTHONUSERBASE is set or not should not matter, but in ubuntu it does. Let me try to show what I mean with an example:

Create a setup.py containing just:

from distutils.core import setup; setup(py_modules=['bug'])

bug.py is an empty file in the same directory.

Now with PYTHONUSERBASE unset:
"python setup.py install" installs into /usr/local/lib/python2.6/dist-packages/bug.py
"python setup.py install --user" installs into /home/marienz/.local/lib/python2.6/site-packages

With PYTHONUSERBASE=$HOME:
"python setup.py install" installs into /usr/lib/python2.6/site-packages
"python setup.py install --user" installs into /home/marienz/lib/python2.6/site-packages/bug.py

The behavior of "python setup.py install --user" is what I expect: python is honoring PYTHONUSERBASE just fine there. What I do not understand is why PYTHONUSERBASE is affecting "setup.py install" *without* --user. After all the documentation says this sets the *user-specific* site directory, defaulting to ~/.local. "python setup.py --install" *without* --user should not care about what the user-specific site directory is.

[Launchpad Janitor (janitor)]

This bug was fixed in the package python2.6 - 2.6.4-5ubuntu1

---------------
python2.6 (2.6.4-5ubuntu1) lucid; urgency=low

  * Merge with Debian (2.6.4-5).

python2.6 (2.6.4-5) unstable; urgency=low

  * Update to 20100131, taken from the 2.6 release branch.
    - Fix typo in os.execvp docstring. Closes: #558764.
  * distutils.sysconfig.get_python_lib(): Only return ".../dist-packages" if
    prefix is the default prefix and if PYTHONUSERBASE is not set in the
    environment and if --user option is not present. LP: #476005.
  * distutils install: Don't install into /usr/local/local, if option
    --prefix=/usr/local is present, without changing the install prefix.
    LP: #510211.
 -- Matthias Klose <email address hidden> Sun, 31 Jan 2010 22:31:41 +0100

[Matthias Klose (doko)]

fixed in lucid, please check. this should be a candidate for karmic after testing

[Rolf Leggewie (r0lf)]

Karmic has long since stopped to receive any updates. Marking the Karmic task for this ticket as "Won't Fix".