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. :) _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
