[Pythonmac-SIG] PackMan - package variation scheme
bob at redivi.com
Fri Oct 10 18:05:39 EDT 2003
On Friday, Oct 10, 2003, at 17:51 America/New_York, Jack Jansen wrote:
> 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
> right now.
> But there's another set of variables, and that is optional
> 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
> 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.
I like this suggestion on theoretical grounds but it sounds
unnecessarily complex. Reportlab commercial should have a different
name than Reportlab free. PyOpenGL should never be compiled without
Numeric support, PIL should never be compiled without jpeg/freetype
support, although Tk is kinda questionable. This is why we have
scapegoats to compile packages with optimal configuration choices (as
many batteries as possible). If a package wants this kind of
flexibility it should be a "Recommended" thing that's determined at
runtime and not build time. IMHO, libraries like libjpeg should be
wrapped from Python and used like that by packages like PIL, rather
than having 10 packages that use libjpeg's functionality in their own
way. If you have to link to a library at build time, you ought to be
exporting as much of that library's functionality that could possibly
This just sounds like a chore to implement for relatively rare
situations and I'm definitely not interested in writing the code for it.
More information about the Pythonmac-SIG