covered in the requirements list, under "meta-data". The only thing I had in mind there, though, is that the distutils would have some way of representing and comparing version numbers -- largely a passive role. RPM-style upgrade/downgrade support was not in mind, but it's a possibility.

Judging from how I use RPM, updates could be more frequent than installation!

...

- Package installation via FTP/HTTP from a server. That may seem like a minor convenience, but once you realize how many system administrators don't know how to use FTP, it gains importance...

I'm not entirely sure what you mean here. One possible interpretation is the following scenario:

At the simplest level it would be like RPM, i.e. you could specify an URL instead of a package filename. Then of course more intelligence could be added to help the user with finding a server that has a specific package or finding a package that solves a certain problem. But that sounds like something for DistUtils 2.0! First there must be enough DistUtil-enabled packages around before automatic searching becomes useful.

The plan is to stay away from Makefiles except for people who want and can benefit from them (mainly developers writing collections of C extensions under Unix). As long as you can run the compiler and linker

Fine. Anyway, Makefiles and make are not essential for compiling code. But calling a compiler from a Python script may be hard enough if all you have is an IDE!

(However, I am a raving Unix bigot and delight in my ignorance of bitty-box platforms like Windows and Macintosh. Anyone who actually

Me too, and I hope I can remain ignorant about them for a long time ;-) But even for Unix, we should plan for maximum flexibility. The current Makefile.pre.in system (based on the information gathered by autoconf) is not really sufficient; for example, it doesn't work for AIX unless Makefile.pre.in is patched manually (and even then it's not flexible enough to deal with all situations!). At worst, we'd have one platform-specific module in DistUtils.

sort of configuration code. However, I think it would be useful to provide some of the functionality that Autoconf provides, e.g. Python classes and/or functions to check for a particular C library, or C include file, or see if a certain token is defined, or if a certain

Right. Otherwise everyone will have to start from scratch.

It certainly doesn't deal with cross-platform issues. One of the things I love about Perl is the towering arrogance of the whole Perl community regarding the utter and complete superiority of Unix over those "other" so-called operating systems. Last time I checked, the semi-official

Hey, maybe I should take a closer look at Perl after all... ;-)

Thanks for catching my slips in the requirements list. Anyone else notice anything? Or have any wish-list items? Now's the time to get 'em in...

Nothing fundamental, but I just remembered one detail that many extension module writers overlook: if an extension module provides header files for use by other extension modules, they must be installed in a public place as well and the compilation system should take care of including this public place in the include directory list. There is no provision for this at all in the current Makefile.pre.in procedure. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------