[Distutils] setuptools 0.6a9 is released

[Phillip J. Eby]

At 01:23 PM 1/4/2006 -0600, Ian Bicking wrote:
>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.

Note that the resolve() method of WorkingSet does this - it returns a list 
of distributions, or raises either VersionConflict or 
DistributionNotFound.  Unlike require(), it does *not* alter the contents 
of the WorkingSet you call it on, and it also allows you to specify an 
'installer' callback that will be invoked for distributions that aren't found.


>   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.

I'm not sure I followed everything you said, but note that entry point 
definitions can list "extras" that will be require()'d when the entry point 
is loaded, and it is recursive.  So, I anticipate that some "nest" commands 
will list extras that would be installed on demand, similar to what 
buildutils does.  So, if for example somebody wrote a web UI for doing 
package management based on TurboGears or Paste, running "nest webui" could 
first download and install the needed packages before firing up the UI.  :)