[Distutils] setuptools: package management and explicit version numbers

[Phillip J. Eby]

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.