"Barry A. Warsaw" wrote: > > 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. Why not put put the updated email package into the Mailman package (is it a package?) ? That way you can update whatever part you want from the Python lib or replace it with something else. > 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. I guess this is done for the same reason that e.g. /usr/local is last in PATH on Unix: system top level programs and libs should always have top priority. Otherwise, a user could easily override a system program/lib by placing a new version into the local dir which then gets picked up by other system programs. I'd suggest to better be explicit about what you do and to put the new code in the package (which is completely under your control). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4