[Pythonmac-SIG] PackMan - package variation scheme
Jack.Jansen at cwi.nl
Fri Oct 10 17:51:17 EDT 2003
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
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
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
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
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
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
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
More information about the Pythonmac-SIG