Hi, This issue first surfaced on the MacOS SIG list, but seems to be a more cross-platform issue. The Python distribution, and distutils, knows of two types of packages/modules: those in the core distribution and the site-packages. This is fine when Python is locally installed anyway, but now that Python is distributed as part of the OS on some systems (e.g. Linux and MacOS X) there seem to be more levels at which you can install packages: between the core python packages and locally installed site-packages are packages installed by the system vendor. As Jack noticed on the MacOS Sig list there are actually even more levels of packages: 1) part of the python core 2) part of the system vendor packages 3) locally installed network-wide packages 4) locally installed system-wide packages 5) locally installed user packages Items 2 to 5 are currently lumped together in site-packages. IMO it would be usefull to define a mechanism to define these levels of package collections, and to teach distutils about them. This would make it easier for system vendors to keep the packages provided by the system seperate from locally installed packages. A related issue is that the site-packages is usually stored in the same part of the OS tree as the python executable, e.g. /usr/lib/python2.3 if the executable is in /usr/bin. This means that local python packages will be installed into "os vendor space" when python is part of the system software. I think it would be prudent to define a policy on how system vendors should deal with this. The Apple distribution of Python 2.3 in Panther solves this problem by moving site-packages to "system admin" space using a symlink. This is a less then perfect option because some Apple provided python packages are in the site-packages directory, and therefore in "system admin" space. Is this really a problem worth writing a PEP for, or am I seeing ghosts? Ronald P.S. As this is my first post to python-dev, I'd better introduce myself :-). My claim to fame is PyObjC, the bridge between Python and Cocoa on MacOS X. I've been a (happy) Python user from about release 1.2 (mostly on various Unix flavors and returning to the Mac with MacOS X)
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