[Distutils] setuptools 0.6a9 is released

[Phillip J. Eby]

At 12:42 PM 1/4/2006 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>The next release of setuptools will be 0.6a10, for which I plan to add 
>>shared library building support (it's needed for an OSAF project, 
>>PyICU).  There are also some minor features (like dependency_links) that 
>>didn't make it into 0.6a9 but which aren't big enough to need waiting till 0.7.
>
>How about logging of some sort?  I'm frequently encountering problems now 
>where I don't understand why there's a conflict or why something is being 
>required.  I attribute this to a larger network of packages and 
>dependencies, and handling more versions of software.  Mostly the 
>information I'm looking for is a path of requirements -- what caused what 
>else to be required, and in what order.  I see that "VersionConflict / XXX 
>add more info" message a lot too, so that's the XXX I'd like to see fixed.
>
>I can submit a patch for some of this if you can advise how you'd like to 
>see that work.  The logging module?  Just a verbose or debug mode of some 
>sort?  Though post-mortem why-did-I-get-this-conflict information would be 
>really nice too, which would imply tracking the information all the time 
>instead of just in a debugging mode.

The reason I have the "add more info" comment is that resolve() could track 
what distributions had what requirements, so the error could potentially be 
something like:

VersionConflict: foo 1.2 conflicts with foo>=1.3 needed by bar 1.7, spam 
2.1 while resolving dependencies for SomeProject>0.8

If that's all you're looking for, it wouldn't be hard to make resolve() do 
it.  Of course, that doesn't tell you the full story if there are more 
layers of dependencies, but I think maybe a detailed dependency analysis 
tool should be part of the "nest" command suite in the setuptools 0.7 
series.  Something like "nest analyze 'SomeProject>0.8'" to dump out all 
the dependencies and how they are currently being met and/or conflicting.