> 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(a)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
-------------------------------------------------------------------------------
