[Distutils] setuptools 0.6a9 is released

[Ian Bicking]

Phillip J. Eby wrote:
> 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.

Since I'm requiring packages from places other than requires.txt (e.g., 
config files) the nest command seems like it would be limited in what it 
could provide.  Not useless, but limited.  Runtime logging would be more 
complete in those situations.  Or maybe just some way to indicate what 
requirements a config file implies, or otherwise wrap that analysis.  If 
I want to analyze a paste.deploy config file, it really comes down to 
parsing out each section, and creating a list of requirements for each 
section, and then displaying the analysis results of that list.  Then 
I'm guessing there would be an entirely different command that would 
analyze paste.deploy config files.

Any particular plans for nest?  We'd talked briefly about paster serving 
as a basis (with some portions removed and put in paste.deploy, where 
they probably already belong).  Mostly it's just command-line UI, but 
the one more architectural issue is how plugins are picked up.  I'm 
pretty happy with the .egg-info config file (paster_plugins.txt) that 
lists requirements (frameworks, typically) of a package, and entry 
points are brought in based on that.  Though, now that I think about it, 
requires.txt might be perfectly usable for that (recursively bringing in 
all requirements, or just the immediate requirements? -- I'm thinking 
just immediate).  Anyway, this applies to a package in development; I 
haven't really thought through how it applies to an installed package. 
Commands could still be installed globally, but for many commands that's 
not appropriate.

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