[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-catalog-sig
Subject:    [Catalog-sig] Fwd: [Pythonmac-SIG] Install manager engine available
From:       Jack.Jansen () cwi ! nl (Jack Jansen)
Date:       2003-02-11 10:28:10
Message-ID: 846613F9-3DAB-11D7-8CF6-0030655234CE () cwi ! nl
[Download RAW message or body]

Andrew Kuchling suggested I also post this announcement here. I was 
actually going to keep this module
more-or-less secret until 2.3 is out, because I need it for a very 
specific problem and I at this moment
I don't have the time to go into full-fledged design discussions (and 
an install manager can be an
incredible sink of design effort:-). I'll elaborate a little on the 
design below, though.

Begin forwarded message:

> From: Jack Jansen <Jack.Jansen@cwi.nl>
> Date: Mon Feb 10, 2003  17:07:48 Europe/Amsterdam
> To: pythonmac-SIG@python.org
> Subject: [Pythonmac-SIG] Install manager engine available
>
> Folks,
> the install manager for Python we discussed last fall is available. At 
> least: the engine is. At least:
> there's enough of the engine that it managed to install Numeric and 
> PIL, and actually notice it had
> done so:-)
>
> It is called the Package Install Manager for Python and it lives in 
> Lib/plat-mac/pimp.py. If you wonder
> about the name, think that "it may be shabby, but it gets you what you 
> need" :-) There's docstrings
> all over the place, and that is also the only documentation. The pimp 
> module has a minimal commandline
> interface, I'm going to work on a GUI next.
>
> It only works for Python 2.3a1 on MacOSX 10.2 at the moment, but I 
> would at least like it to work
> for older Pythons and older MacOSX releases as well, so any help there 
> is appreciated.
>
> I would like it if people could test this with other packages (wxMac, 
> PyOpenGL, PyObjC, etc), and if
> they could test it with binary packages. For 2.3a2 I would like to 
> have a sizable number of packages
> in there (at least the 5 mentioned above, maybe more). During 
> development I guess it's probably best
> if I am the maintainer of the pimp database, but I would like to push 
> that responsibility off as soon
> as possible, so if anyone feels like doing this: please speak up!
>
> If you try this with your favorite package and notice there is 
> functionality missing: speak up! I would
> like to keep functionality as minimal as possible, but no smaller. (As 
> an example: I had to add the preInstall
> functionality today because "python setup.py install" isn't enough for 
> PIL. You need to run configure
> and make too).

The specific problem this module is designed to fix is that the 
MacPython community has grown accustomed to
MacPython coming with "batteries included", the distribution contains 
popular packages like Numeric and img.
I don't want to do this anymore for MacPython-OSX. The intention is 
that Pimp will make it so easy to install
selected extension packages that to the end user it is almost as good 
as having the package included in
the distribution. Possibly even better, because you don't have to 
download packages you don't want.

Because of the target audience I've made a couple of design decisions:
- Pimp shouldn't depend on a development environment, i.e. it should be 
able to handle binary
packages (and these should be the default).
- If a package is listed and the end user tries to install it this 
should work correctly 100% of
the time.

Especially the latter leads the design in a specific direction. First, 
the database of packages (which
is loaded over the net) is specific to a (os-version, python-version) 
combination and there's a maintainer
of the database who is considered responsible that everything in the 
database actually works. Second,
MD5 checksums of the package archives are kept, so if package authors 
change a package and the database
maintainer hasn't noticed (at which point s/he would presumably test 
the new version of the package and update
the database) the end user is warned about the package being untested.

Pimp handles dependencies, and it can also handle dependencies to 
things it can't install itself (i.e. all
packages that come as source depend on the Apple Developer Tools) in 
which case the user is told
how to proceed if the dependency isn't available.

Unlike fink or inst or some such it doesn't keep a database of what it 
installed, in stead it actively figures
this out on the fly. This may need to be changed when we want to do 
uninstall, but the idea is that it should
remain as robust as possible, and not get upset if people install or 
remove things behind its back.

 From a first look at pypi I think pypi and pimp together could form a 
winning team. I'll read up on pypi and
I'll join the catalog-sig to see whether the issues mentioned above are 
handled in pypi, and/or think of how
they could be handled.
--
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



[prev in list] [next in list] [prev in thread] [next in thread]