[Python-Dev] Order that site-packages is added to sys.path
Barry A. Warsaw
Tue, 12 Feb 2002 00:09:06 -0500
I have a bit of a dilemma when it comes to sys.path and the location
of the site-packages directory.
The problem comes when someone is using Mailman 2.1 with Python 2.2.
The latter comes with the email package, which is in the standard
library. Through some contributions, my standalone email package now
supports multibyte character sets in RFC-compliant ways
(e.g. splitting long headers correctly). The question is, how do I
get the updated package to Python 2.2 users?
The standalone email package is a simple distutils thingie with a
directory and a bunch of .py files. distutils sticks this in
site-packages. But an "import email" will always get the standard
library version instead of the site-packages version because site.py
/appends/ site-packages to sys.path instead of prepending it.
I can work around this by adding my own path-hacking code before any
import of email.* modules. This is a bit ugly because now it means
that the proper functioning of the application depends on import
order, and that's nasty.
So the question is: why does site.py append site-packages instead of
prepending it to sys.path? If there's a valid reason, I don't
remember it, and I'm currently blind to any valuable use case. If
there's no good reason, it would seem to me that the following use
case is better served by prepending:
- We want to provide an enhanced version, or a fixed version of a
module or package. Distribute it w/distutils and do a normal
install. As long as you don't start Python w/ -S, you'll always get
the improved version. Don't want the improved version? Start
Python w/ -S or just don't ever install the new package.
I'm mostly looking for rationale right now, before I try to decide
whether it's something worth debating and/or changing.