[Distutils] setuptools site-package pollution

[Phillip J. Eby]

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.