setuptools 0.6a9 is released
This version contains mostly bug fixes and robustness improvements in a variety of areas, ranging from improved web spidering to better handling of spaces in the Windows directory names for generated .exe files. The biggest new feature included, however, is system packager support including improved bdist_* command handling, and support for installing projects in a "single version, externally managed" format. You can now also build RPMs and Windows installers of setuptools-baseds project without any special steps, even if the project uses egg metadata. The other new features are for developers of setuptools-based projects, and mostly have to do with improved handling of source distribution manifest generation and specifying package data to be included in a project. You can now simply specify "include_package_data=True" and any file under revision control or listed in your source manifest (or MANIFEST.in) will be installed as part of the package. There is also an 'exclude_package_data' option that can be used to trim back the list, and the 'package_data' option can still be used to add files that aren't in revision control or the source manifest. Finally, there have been many documentation updates, including an overhaul of the installation instructions and a new "What your users should know" section of the setuptools manual for project developers. 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. Special thanks to Kevin Dangoor, Ian Bicking, and everyone else who reported bugs or helped track them down. Thanks to your participation, 0.6a9 is in much better shape than 0.6a8, and I look forward to a great 0.6a10!
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. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
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.
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@colorstudy.com / http://blog.ianbicking.org
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. :)
participants (2)
-
Ian Bicking -
Phillip J. Eby