[Distutils] Buildout not updating setuptools

[Jim Fulton]

On Jul 9, 2007, at 11:42 AM, Phillip J. Eby wrote:

> At 07:33 AM 7/9/2007 -0400, Jim Fulton wrote:
>
>> On Jul 8, 2007, at 12:56 PM, Phillip J. Eby wrote:
>>
>>> 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.
>>
>> Really? Why?  If this is true, then "develop" seems to be a misnomer.
>
> Yep - which is why I've been referring to them as "egg-info" or  
> "single version, externally managed" eggs.  :)
>
> The code still uses one symbol for DEVELOP_DIST because the  
> selection precedence of such eggs is the same, regardless of  
> whether they're generated by "install" or "develop".

IMO, they shouldn't have the same precedence.  IMO installations made  
with the develop command should have the highest precedence. After  
all, why would someone use the develop command if they didn't want to  
see the effects of changes they're making in development.  Could we  
can change the develop command to generate a different symbol, like  
REALLY_DEVELOP_DIST and give it the highest precedence?  (Tempted to  
wink, but not really kidding...) It appears that it doesn't actually  
generate anything atm, but I think it should.


>>> 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.
>>
>> But you can't look for an egg-link file if all you have is a
>> distribution.  The dist location points to the contents of the egg
>> link file.  How is one to determine, given a DEVELOP_DIS egg in an
>> environment whether it was created by the develop command?
>
> I didn't say it was easy.  ;)  You'd have to check for .egg-link  
> files along the environment path, and see if there's one that  
> points to the distribution in question.
>
> One possible distinction is that distutils generates .egg-info  
> *files* with version information in the file name, and setuptools  
> "install" and bdist packages include the version information in the  
> directory name by default.  So you can rule out any egg for which a  
> versioned filename exists as not being "develop" targets.
>
> Unfortunately, you can't assume the reverse: just because it's  
> an .egg-info directory and *doesn't* have any version information,  
> you don't know for sure that it was generated by develop.  It could  
> be a system package produced by one of those people who likes to  
> tinker, and decided to remove the version info from the directory  
> name for some crazy reason.  OTOH, you could just say the heck with  
> 'em.  :)
>
> You can easily check whether the .egg-info is a file: if it's a  
> DEVELOP_DIST, and ``dist.list_metadata('')`` contains 1 or 0  
> entries, it's a metadata file, and definitely not a develop.
>
> In order to check the directory version info, you'll have to steal  
> a peak at the ``dist._provider.egg_info`` path and see if it's got  
> a '-' in it before the '.'.  If yes, it's not a "develop"-generated  
> egg.

So I guess there's nothing actually stored in the egg info do  
indicate that it was built with develop.

I'll have to think about what this means for buildout.  I suppose I  
should simply treat anything in the buildout's develop-eggs directory  
to be deserving of special treatment and ignore the precedence.   
Things will only get put there when buildout invokes the develop  
command or by the custom egg builder, whos output should get special  
treatment that it''s not getting now.

Thanks for, um, clarifying this for me. :)

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org