[Distutils] setuptools: .egg-info/ and PKG-INFO

[Ian Bicking]

Phillip J. Eby wrote:
> At 01:09 PM 11/4/2005 -0600, Ian Bicking wrote:
> 
>> Well, like I said, any custom command.  These just inherit from 
>> setuptools.Command, implementing the standard 
>> initialize_options/finalize_options/run methods.  I even tried having 
>> my custom command recursively call "egg_info" (with 
>> get_finalized_command), but because the error is signaled before I get 
>> as far as .run() (where I put the egg_info call) it doesn't help.  
>> Maybe I could use another method that is invoked earlier.
>>
>> Though now I can't reproduce it; maybe this was fixed in 0.6a7?
> 
> 
> Dunno.  As I mentioned on the Turbogears list, the problem isn't going 
> to happen if your source code is in a subdirectory of the one containing 
> setup.py.  Perhaps you've changed layouts?
> 
> In any case, as I mentioned on the Turbogears list, I'm going to try to 
> put in some code to detect whether there is a "broken egg" in the 
> working set and monkeypatch its 'version' attribute to work around this 
> bootstrapping problem.  That should make it more robust and eliminate 
> the need to include any of the .egg-info files in Subversion, at least 
> for most normal projects.  (Setuptools is an oddity in that it defines 
> entry points that it then uses while building itself!  Its 
> .egg-info/entry_points.txt file is therefore not optional.  But the need 
> for this sort of self-bootstrapping setup process should be extremely 
> rare.)

FYI, I'm already putting my own custom files in the .egg-info/ 
directory.  And sqlobject-admin now looks for a sqlobject.txt file in 
the egg metadata, which it uses to find the SQLObject subclasses in the 
project (and a couple other things).  These could all possibly be moved 
to entry points, but treating them as simple configuration files has so 
far seemed easier to manage.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org