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

[Ian Bicking]

Sorry, I somehow missed this response...

Phillip J. Eby wrote:
> At 04:30 PM 10/25/2005 -0500, Ian Bicking wrote:
> 
>> I'm trying to figure out how I should deal with the .egg-info directory,
>> and PKG-INFO.
>>
>> Right now PKG-INFO is being generated from setup.py.  So I don't want to
>> put it in my source control repository, since it is derivative.  But I'm
>> maintaining by hand some other files in the .egg-info directory, usually
>> custom package metadata that we consume internally, so I need those
>> files (and .egg-info) in the repository, and hence in the checkout.
>>
>> However, without PKG-INFO lots of things break, as pkg_resources gives a
>> ValueError during some operations (e.g.: ValueError: ("Missing
>> 'Version:' header and/or PKG-INFO file", ProjectName [unknown version]
>> (/usr/home/ianb/co/IscapeLib/tests/appsetup/output/Proj-05))) -- this
>> happens anytime I iterate over entry points, including when setuptools
>> iterates over entry points, which means lots of setup.py commands are
>> broken.  They are broken simply because the incomplete .egg-info
>> directory is on the path, even though I don't need direct access to it.
>>    I can run setup.py egg_info (creating PKG-INFO) for some reason (that
>> I have not yet determined), but not my own custom setup.py extensions.
>> This includes stuff like "python setup.py egg_info my_custom_command",
>> so I have to write PKG-INFO in a completely separate command.
> 
> 
> 'setup.py develop' should create the info and put the directory on the 
> path for you.  Likewise, so does 'setup.py test'.  Which other commands 
> are giving you problems?

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?

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