[Pythonmac-SIG] What is the future of Python on OSX?

[Jack Jansen]

On zondag, september 8, 2002, at 02:56 , Kevin Ollivier wrote:
>> Let me take a shot at an initial database format. I'm making 
>> this up as I go, so there's probably holes in it. The XML file 
>> has a head section with the DTD and version and other 
>> mumbo-jumbo, and the body is a list of packages. A package 
>> consists of a name, a version, a one-line description, a URL 
>> at which the user can find out more information, a list of 
>> dependencies, an existence test script and an install script.
>>
>
> Don't know if I'm getting too detailed at this early phase, but 
> I'd suggest that there be a list of categories as well.

I'd like to postpone this to phase 2. There's lots more 
meta-information you may want to include (and that we will need 
to include before SPAM can live up to it's name). Name, 
short-description and long-description-url are the only ones I 
think are essential for version one. Actually, let's call this 
thing not version 1 but version 0.9.

>> Of these I think only the latter three pose some interesting 
>> questions. Maybe the list of dependencies shouldn't be a list, 
>> but also a script, so you can test for specific versions of 
>> packages on which you depend? That way you could also use 
>> gestalt to test for specific OS versions or other things 
>> outside the control of the Python Install Manager, but on the 
>> other hand declarative is usually better than procedural. But 
>> for a first stab it would allow, say, the Tkinter dependency 
>> script to test whether AquaTk is installed and, if not, tell 
>> the user to read the "more information" document where you can 
>> post detailed instructions on how to install AquaTk yourself.
>
> I think the list approach is better because it lets you reuse 
> the package information you've already entered into the system. 
> My application, for example, would have PyXML and wxPython as 
> dependencies. Since those packages would be in the database and 
> have their own existence test scripts, I would only have to 
> write a script for my own package and specify that the wxPython 
> and PyXML packages must pass their existence tests before my 
> package can be installed.

I would assume that dependencies cascade, i.e. your dependencies 
would only be PyXML and wxPython, and not include their 
dependencies again. [thinking] Yes, we definitely want to do 
direct dependencies only, not indirect one. Let's assume that 
OSX 10.3 includes AquaTk. Then we want to update only the 
Tkinter dependecy script to cater for this, not everything that 
uses Tkinter.

But, all that said, there is a point in here. One of the 
problems with CPAN, when I tried it years ago to get a program 
to sync my Palm to my unix machine, was that it gave you one 
level of dependencies only. So after loading a couple of 
packages I had another set of missing packages. When I loaded 
those I had yet another set. And so on until I abandoned the 
whole idea:-). So, there's two lessons in here:
- The dependencies script should report *all* missing 
prerequisites, not just the first one.
- It should, if possible, do so in a way that can be interpreted 
by the PIM, so the PIM can run the dependency scripts of the 
missing prerequisites too. I say "if possible" here, because for 
external dependencies this won't work (they might even be of the 
form "you need a machine with a faster CPU").

> Just a thought that popped into my head: what about an 
> uninstall script? Should that be added into the package 
> information?

I think this is the responsibility of the distutils folks. Hmm, 
but this does mean that the PIM should keep package source 
around too. Or, at least, have a preferred location where the 
downloaded package (as opposed to the installed package) is kept.

> I think a "last updated" date should also be included. 
> Eventually, this would enable the PIM to warn users that they 
> need to go online and update their package database when it 
> gets old.

I think the database will initially be small enough that it can 
be loaded whenever you start the PIM. And by the time it's too 
big for that to be comfortable we can use http caching info to 
forestall downloading. And by the time it changes too often even 
for that  we're at SPAM v3.0 or higher at least:-)

But what might be nice (and not too difficult) is if the PIM has 
two incarnations: the one included with the distribution (lets 
call this "pimbase") and a user-installed one, which may be more 
recent (let's call this "pim"). The PIM GUI would first try to 
import pim, and if that fails it would import pimbase. If the 
pim or pimbase, after loading the database, would see from the 
version numbers that it is too old it would offer to update 
itself. The update would proceed by the normal means, the new 
pim would be installed in site-packages and the user could try 
again. This way we can update the PIM database structure without 
waiting for a new Python release: we would just replace the old 
database with a tiny one only offering the newer pim package. 
And we don't have to maintain databases for a plethora of pim 
versions: the older ones would only offer the pim upgrade. The 
URL at which to load the database would be embedded in the pim 
package, so we could also switch to a distributed scheme later, 
or a different webhost, or whatever. It does mean that the pim 
API can never change in an incompatible way (as then the PIM GUI 
wouldn't be able to communicate with it) but that's a small 
price to pay.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -