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

[Jack Jansen]

I'll reply at once to various messages here.

On zaterdag, september 7, 2002, at 12:57 , Samuel Smith wrote:
> A useful feature that would help a common beginner problem is 
> to update the python path to make sure all the "installed" 
> modules are reachable and to report any obscured modules due to 
> a duplicate in a higher priority path.

I think that it the "test whether the module is installed" 
should handle this. I.e. if something is found on sys.path it 
exists, otherwise it doesn't. And if we require (or, I should 
say, if the archive maintainer requires) that all Python 
packages are distutils-based then everything will end up in 
site-python anyway.

For the long run we may want something like systemwide 
installation/per-user installation/network installation, but for 
a first stab I'd like to apply the KISS principle.

Kevin Ollivier wrote:
> I've been thinking about that myself. The database could 
> actually be run off the web and output an XML file which the 
> Python Install Manager client software would read.

That would definitely be the most sensible approach. We have all 
the tools to download and parse XML, after all. And we get a 
versioning scheme whereby we can keep things simple initially 
and extend our DTD later when we understand the problems better.

>  Making it web-based would enable the developers themselves to 
> go online and add their package information to the repository.

I think that initially I would like to go with a centralized 
scheme, i.e. appoint one (or a few) people responsible for the 
database. I also think that we should initially aim for 
something that supports the major packages (pyobjc, tkinter, 
wxpython, numeric, opengl, pil, piddle and maybe a few more), 
and that the Database Czar is morally responsible for testing 
the installers before putting them in the database.

>  For the more complicated stuff, we could let the developer 
> specify "pre" and "post" install  scripts for dependencies 
> without bloating the database format. We could also work on 
> getting it hosted by the PSF on python.org, that way ensuring 
> that it will be maintained.

Again, I think we should slow down a little here. If at first we 
aim for MacOSX only we can learn some lessons that we can then 
apply to a generalized Searchable Python Archive of Modules. 
Yes, that name is brilliant, it makes you wonder why the perlies 
put up with CPAN:-)

Mirroring and such (as Alexandre mentioned) I think we should 
also put off to a later date. It's very easy to add on. Same for 
things like digital signatures and version verification (which 
you definitely want when you do mirroring). And for a SPAM we'll 
also need to address multiplatform issues, source/binary, 
searchability on keywords (otherwise SPAM won't work:-0) and 
more like that. And if we allow any developer to enter stuff 
into the database we need a feedback scheme on what has been 
known to work on what platform, etc. And I have this pet feature 
I want to add (but at a much later date): a list of 
modules/packages that the package will provide when installed. 
That way, if you get an obscure script from someone that does 
"import foobar" the IDE could catch the import error and point 
you in the direction of the package you might want to install.

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.

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.

And for all three scripts there's the question of whether 
they're included inline or referenced by URL. I lean towards 
including the existence test script inline (so the PIM can 
quickly show installed/not installed status) and having the 
other two referred by URL (because there's no need to load them 
if the end user couldn't care less about a certain package).

Oh yes, the version information in the head section should not 
only include the database version but also the version of the 
PIM: if the inline scripts are to be of acceptable size then the 
PIM should setup an environment in which the scripts are run 
(and for instance pre-import such goodies as sys, os, string, 
gestalt, etc).

Hmm, and now that I read that AquaTk sentence again I think 
there are actually 4 states in which a package can be (according 
to the existence test script):
1. It's not there
2. It's there, it's up to date, everything's fine
3. It's there, but you have an old version
4. It's there but it doesn't work, you've probably messed up 
some of the dependencies or something else is going on that the 
PIM can't help you with.
--
- 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 -