[Pythonmac-SIG] PackageManager maintainer questions

[Jack Jansen]

On Monday, May 26, 2003, at 13:12 Europe/Amsterdam, Andrew Straw wrote:

> I'm thinking of becoming the maintainer ('scapegoat' in Jack-speak) 
> for a few Python packages.  In particular, thinking about maintaining 
> the Mac OS X port of the pygame package brings up some questions.

Yeah!

> How is a non-power-user supposed to do a site-wide install of 
> anything?  (I used 'sudo pythonw PackageManager.py'.)

I never thought about this. The next version of the binary installer 
will use group-writeable for all files, so any admin user can install 
packages, but I never thought about non-admin users wanting to install 
things system wide. I think the sudo trick won't work, because I think 
non-admin users aren't allowed to sudo.

> Is the XML database format stable(ish)?

No, there are a few things that need fixing. The main one is 
<http://www.python.org/sf/731626>. This one _must_ be fixed before the 
2.3b2 release, because if we have it in place then we can do the rest 
of the fixes lazily (by having pimp auto-update itself). I don't know 
yet how to go about this, though. The reasonable thing to do is that 
the pimp module becomes something of a meta-module that does something 
like "from pimp_X_Y import *" for the most recent X_Y on your disk. But 
pimp_X_Y should be able to live in various places, such as 
site-packages or the per-user site-packages.
But if the pimp version needed is encoded in the database then we won't 
know the version we need until we have already done a whole lot of 
stuff, with the current pimp architecture. Any ideas are welcome...

Another issue with the database is that I want to packages to have an 
entry "files that are expected not to be installed when you do a 
per-user install" so we can tell the user the difference between 
expected skips and unexpected skips. A third one is that packages need 
a description, and this has to go into the UI. A fourth one is that we 
need a flag that a package cannot be installed per-user. a fifth one is 
that we need multiple databases (see below).

> I created my own test .xml database with only a single, pure-python 
> package.  For some reason, it comes up as installed ('yes' in the 
> first column) despite the fact there's no package of that name in the 
> site-packages directory.  How is the installation status checked?  (It 
> installs fine if I click 'overwrite'.)

You need to write the test yourself. See the examples in the default 
database, the simplest test is "import foo", more complicated tests 
also check the version number in foo. Ask again if these aren't clear.

> I wonder what the best way to deal with c libraries is (e.g. in 
> /usr/local/lib).  In reference to pygame, there are a few libraries 
> used by both SDL_image (a dependency of pygame) and wxPython (another 
> nice Python package).  The dynamic linker won't let you use 2 versions 
> of the same library. In the past, I've resolved this by installing 
> such libraries (IIRC libpng, for example) on the system by hand.  Then 
> I would compile wxWindows and SDL_Image myself to use the system 
> versions of this rather any pre-made version with pre-compiled 
> libraries.  How do CPAN or other systems deal with this?  Jack, is 
> this part of what you had in mind with the hidden packages?  I guess 
> PackageManager may have to handle (or at least know about) libraries 
> that aren't in Python.

Yes, hidden packages are a part of this. See the Tkinter and PIL 
packages for an example of how to do this. The one shortcut that I've 
taken is to require that third-party libraries live in a specific place.

> Is a database of databases a useful idea?  I can't envision Jack 
> maintaining *everything* (although he does a great job at coming 
> pretty close!) and I might be willing to trust other database 
> maintainers. Might it be good to have a list of HTTP-accessible .xml 
> databases that could be accessed from within PackageManager?

The code is already there, but it hasn't been tested. A database can 
include other databases. How I envision this works is that there is one 
Ueberscapegoat, who is the only point of contact for end-users. This 
Ueberscapegoat can delegate maintainance tasks to normal scapegoats, 
who each maintain their own databases (which the ueberscapegoat 
includes into the master database), but the ueberscapegoat remains the 
person "responsible" (whatever that means for open source software:-).

Now that you have something: let's give the multiple-database code a 
try!
>
> Finally a note of thanks to Jack and all others involved: this stuff 
> is great!  It seems MacPython is rapidly becoming the easiest of all 
> Pythons to use!

As it should be, as it should be.... :-)
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman