At 01:00 PM 8/10/2005 -0500, Ian Bicking wrote:
Has there been any progress on some of the package management tools people were talking about? I.e., list and delete packages? (At the moment no other features come to mind, but I'm definitely seeing a purpose for these functions) Someone said they were going to give it a go, but I can't remember who.
It was Paul Moore. I recently had a look at Ruby's "gems" system, which is surprisingly similar to setuptools and Python Eggs, except that they also have the list and delete functions, functions to verify signatures and check installation integrity, and a command to run a package index server off the information in the gems you have installed! I'm thinking that in the long run (i.e. after I get the pkg_resources manual finished), I'll make a 'nest' script along the lines of their 'gem' program, and use that as the place for adding the list/delete/upgrade stuff. One interesting benefit to the server concept is that you could use it to create a browser-based interface to browse through eggs' contents. I suppose you could also include options to install/upgrade/delete eggs as well, at least if you have an appropriate way to restrict access. It would let us implement a cross-platform GUI for setuptools. Of course, I doubt I'd bundle it directly with setuptools. Instead, I'd just define an entry point for the server command in the setuptools egg, with an "extra" set to download the egg with the actual server functionality. In fact, everything except the "nest" script itself and the "install" command (which would be an alias for easy_install, such that 'nest install foo' == 'easy_install foo') could be in separate "nest eggs". :)
Another option that I think would be useful is to modify requirements in a package to make version numbers explicit. So I might have something in development and it requires a bunch of packages. It just requires the Most Recent version of those packages; I haven't tested anything but that, so I don't know if older versions would work, and I can't know if newer versions will work.
When I get ready to release, I want to be conservative. Which means that I know that the exact versions I am using work well, but nothing else; I don't know that past or future versions of the packages I depend on will work. So I'd like to change my requirements so that they specify the exact versions I'm using at the time of release.
As I think about it, it sounds pretty easy really. I just find all the requirements, see what version is installed, and rewrite requires.txt with those versions. At first I thought it should be a package management function, but should this be part of setuptools? A new command, or maybe an option to egg_info? It seems like it fits into egg_info well. This means requirements should be specified only in requires.txt, not in setup().
Ugh. Well, you could do that, but you're going to get a warning about requires.txt being defined but no requirements specified in setup(). It probably makes more sense to have a function that takes a set of requirement strings and returns new requirement strings, and put that in setup().
There's some other features I can think of specifically using subversion together with setuptools, but maybe I'll mull on those a bit longer. Nothing fancy, but codifying a specific pattern, something like:
easy_install.py -e -b dev package_name cd dev/package_name # I would like "in-development" packages to have some specific version # but I don't know what that version should be...? sudo python setup.py develop -m # time passes, development is done, release is ready... python setup.py svntag 0.5 # changes PKG-INFO with new version, copies trunk to tags/0.5, does an # svn switch
huh... maybe I can add such a command with an entry point?
You can add whatever commands you want with entry points. Further, you can define aliases (per project, user, or Python installation) that group related commands and options into a single virtual command, using the 'setup.py alias' command.