On Sep 22, 2005, at 3:04 PM, Rich Burridge wrote:
Phillip J. Eby wrote:
Recently I asked about the inclusion of a "vendor-packages" directory for Python on the Python mailing list.
See the thread started at:
http://mail.python.org/pipermail/python-list/2005-September/ 300029.html
for the full reasoning behind this request, and the replies I received.
I'm with Terry on this, it needs a better rationale. Why can't you just add a .pth file to the site-packages directory? It seems that would address the issue nicely.
(See http://docs.python.org/lib/module-site.html for documentation of the .pth mechanism, which would let you implement a separate vendor-packages directory without modifying Python, and would still allow local overrides of your vendor packages.)
I understand how .pth files work.
The rationale for requesting the "vendor-packages" approach, is that Python files, as supplied by the vendor (Sun, Apple, RedHat ...) with their operating system software, should go in a totally separate base directory, to differentiate them from Python files installed specifically at one site.
Note that Apple already does this via a .pth file ("Extras.pth"), as of Mac OS X 10.4, which points to the following location: /System/Library/Frameworks/Python.framework/Versions/2.3/Extras/lib/ python Currently this location includes wxPython. There is an additional vendor package which they (wrongly) integrated into their patched Python build process so it ends up in the plat-mac subsection of the standard library (CoreGraphics). This is a closed-source not-very- well-done SWIG generated CoreGraphics wrapper that they use for some print filters and such. Note that Python does have additional support on Mac OS X for an additional per-user site directory out of the box (for framework style builds anyway): ~/Library/PythonX.Y/site-packages/ There's also the admin-writable /Library/PythonX.Y/site-packages/, but that's an implementation detail in that Apple made site-packages a symlink to that location. -bob