On 4/13/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > You mean 'get_python_lib(standard_lib=1)'? >
That's much better, thanks. > > System packages are just develop eggs installed in "system" > locations. System locations may be Python-defined or OS-defined. For > example, some distros have non-standard directory layouts, such that there > is both a "/usr/lib/python2.x/site-packages" and a > "/usr/local/lib/python2.x/site-packages", and *either* could contain system > packages. > I think I'll wait till I finish the plugin system for package mangers before I try to guess if its a system package then. If a package manager has a manifest for Python itself I'll be able to determine that wsigref for instance is "owned" by the Python package and therefore a system package. > There is a trick you could use to identify "develop" distributions, > though... if there is a "SOURCES.txt" metadata file associated with an > egg, you can look for a setup.py in a parent directory whose directory > layout corresponds to that described by the contents of SOURCES.txt. This > could *potentially* produce a false positive, though, if the package in > question puts all its modules in the project root and doesn't have any > other files besides setup.py listed in the project root. > > (The long-term plan for 0.7 is that packages that are actually "installed" > will have some kind of installation manifest ala PEP 262.) > > By the way, under Python 2.5, packages installed by the distutils include > an .egg-info *file*, so that is a giveaway that a package was installed > using distutils (and maybe a system packaging tool), and is definitely > *not* a "develop" package. > Ok, great, thanks. I'll use those methods to check also. Rob _______________________________________________ Distutils-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/distutils-sig
