[Pythonmac-SIG] PackMan - package variation scheme

[Bob Ippolito]

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 
> 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.

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 
be useful.

This just sounds like a chore to implement for relatively rare 
situations and I'm definitely not interested in writing the code for it.

-bob