[Pythonmac-SIG] PackMan - package variation scheme

[Jack Jansen]

Now that we're happily arguing PackMan I'd like to toss another issue
into the arena that I don't have a solution for: package variations.
I have some ideas, but I'd like feedback, please.

Currently a package has a name, a version and a flavor. Versions and
flavors are relatively simple to understand (and handle): versions have
an ordering (even though we may have trouble actually determining that
ordering in code:-) and flavors are only interesting during 
installation:
after installation the result is supposed to be identical whether a
package was installed from source or binary. It might be a good idea
to rename flavor to installationMethod, as that is really what it means
right now.

But there's another set of variables, and that is optional functionality
in the package. Let's look at PIL, for example: depending on the
availability of libraries (and Tkinter) at build time it will have
jpeg support or not, freetype support or not and Tk support or not.

I would like it if we could express this in Package Manager. At the 
moment,
you cannot state that a package X depends on "PIL with Tkinter support"
or "PyOpenGL with Numeric support", but there are definitely cases where
you want to be able to say that.

The first thing this would require is a naming scheme, but that's the
easy bit. I think something like PIL/jpeg/tkinter-1.1.4-binary should
do the trick, with some magic in the compare function for 
package/option1/option2
comparisons.
	
	Sidebar: notice that the names becoming even uglier than they are
	now isn't an issue: they'll be hidden by the GUI normally. The
	end user will just see "PIL", and only when s/he chooses so, or there
	is a dependency conflict or something will the PIL package fold
	open to show that there's a lot of flavors and options hiding in
	there.

But the difficult bit is determining what is installed. Currently the
version check returns yes/no/old/error, but it would need to return
much more info. Moreover, it would need to be able to deduce that
info ("does this PIL have freetype support"), and I don't know how
to do this (without Python code in the PackMan database).

Or is this again something we drop on distutils's plate? (Or, actually,
on the database of installed packages that we think distutils should
maintain).

Oh yes: note that I use the example of variations in binary packages
here all the time but something similar can be envisioned for source
packages. Think of something like reportlab, which comes in an open
source version and a more capable commercial version.
--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman