[Distutils] Buildout not updating setuptools

[Phillip J. Eby]

At 07:17 AM 7/8/2007 -0400, Jim Fulton wrote:
>So, the Ubuntu packager for setuptools decided not to install
>setuptools as an actual egg, but as a wonky sort-of develop egg with
>a less than ideal location.
>
>IMO, this is just wrong and broken. Does anyone disagree?

Yes, because it's fine for them to install it as a develop egg; 
that's how system packages are *supposed* to be installed.

In other words, it's not wonky, unless they also changed something 
besides just installing it  .egg-info style.

Thus, if buildout is assuming that "DEVELOP_DIST" egg paths contain 
only modules or packages that are part of that egg, it is broken.

Note, for example, that as of Python 2.5, the distutils install *all* 
packages with an .egg-info file, which is detected by pkg_resources 
as a DEVELOP_DIST.  A plain old Python 2.5 install with stock system 
packages will be chock full of develop-style eggs, in other words, 
even if the packages in question didn't use setuptools at all.

This is by design.

If you want to be able to figure out if something is really a 
"develop" installation, you need to look for an .egg-link file, not 
the mere existence of a DEVELOP_DIST egg.  Only the "develop" command 
writes .egg-link files.


>The good news is that setuptools can repair itself:
>
>    sudo easy_install -U setuptools
>
>Doing this causes setuptools to upgrade itself to a regular egg-based
>install. At this point (at least on my system), I can install routes
>and, when I run buildout, it doesn't create an egg link in the develo-
>eggs directory.  Of course, at that point, you've probably messed up
>your system packaging

Installing setuptools to a $PYTHONPATH directory should work 
fine...  but might not, depending on whether the system setuptools 
has a 'site.py' included, or whether it was removed by some 
busy-body.  The next 0.6 version will have a workaround for this so 
that you can still do $PYTHONPATH installation even if the system 
setuptools was hacked on by an over-eager packager thinking that a 
'site.py' shouldn't be in site-packages.  :)