At 11:07 AM 12/7/2005 +0100, Anthony Tarlano wrote:
Maybe it is just a pet-peeve, but I like to keep a nice tidy site-packages directory, and these long directory names just seem to me to be pollution of my site-packages directory in my command shell.
The purpose is to allow easy removal or upgrade of packages. The normal distutils installation process has no provision for uninstallation or the deletion of obsolete modules when a package is upgraded. Putting each package in its own versioned subdirectory allows comparatively trivial uninstallation and upgrades. This is particularly important if you are using packages that are not provided by a system package manager (e.g. an RPM or Debian, etc.)
For example, during the development of PyProtocols, there have been times where I've deleted or renamed a module. Using the standard distutils installation, this would sometimes result in people's upgrades still having the old modules present. In short, the standard distutils installation process is not manageable without wrapping in some kind of package management tool like bdist_rpm or bdist_wininst.
If there is an option to have just the packages, I would really appreciate someone telling me what it is. If not maybe it could be considered, and to put whatever meta-data the directory names are providing somewhere else..
There is an --old-and-unmanageable option to the "setup.py install" command which will install setuptools-based packages the old and, yes, unmanageable way. It does not work with packages that require the additional metadata - such as setuptools itself. It should be able to be used with RuleDispatch and PyProtocols, at least for the moment. It will *not* work if you try to install packages that declare dependencies on those packages. For example, if you install RuleDispatch using --old-and-unmanageable, then TurboGears will try to reinstall it and warn you about conflicting packages installed the old and unmanageable way in site-packages.
There is another option I'm working on, --single-version-externally-managed, which is designed for system packagers to create old-style packages, but with the metadata included as a separate .egg-info directory. This won't help you, though, because it will result in having even *more* directories in site-packages - the package directories plus an .egg-info directory. Anyway, this approach will be used for future setuptools integration with bdist_rpm, bdist_wininst, etc., since these package management tools are able to handle safe upgrades and uninstallation in a way that the unadorned distutils install process cannot.
Phillip J. Eby:
There is another option I'm working on, --single-version-externally-managed, which is designed for system packagers to create old-style packages, but with the metadata included as a separate .egg-info directory. This won't help you, though, because it will result in having even *more* directories in site-packages - the package directories plus an .egg-info directory.
The package directory is not a problem, one directory needs to be present anyway -- whether it's called "foo" or "foo-VERSION.egg" doesn't matter much.
Maybe it would be a good idea to hide all the .egg-info directories under one common subdirectory, i.e. instead of "foo.egg-info" (or, as you plan IIRC, "foo-VERSION.egg-info"), the metadata would be in something like .../EGG-INFO/foo-VERSION/*.
Advantage: no clutter, less work for every tools because you have to scan through fewer directory items.
I'd go as far as disallowing .egg files in directories which have an EGG-INFO subdirectory, which would reduce scan times even more. Rationale: Either a directory is externally managed, or it is not. (/usr vs. /usr/local.) If it is, shipping an .egg makes no sense -- you don't gain anything by doing that. If it is not, on the other hand installing externally-managed versions makes no sense.