On 15 March 2000, Edward Colbert said:

We would like to use Distutils for installation of our Python front end to IRAF (an astronomical data reduction program). Our front end is called PyRAF. Upon reading the Distutil documentation, I can figure out how to do a basic installation but there are some files that do not seem to install easily with the current version of Distutil (or I am missing something).

OK, you get bonus points (danger pay?) for wading through USAGE.txt. Well done! Better documentation coming Real Soon Now (TM).

First, we need to install several data files and scripts. One is named "pyraf" and is a python script. Another is a database file called pyraf.Database, which is created specifically for each platform by executing a python script mkpyraf.Database.py. Some other data files need to be copied directly.

Installing scripts is an obvious problem with an obvious solution that will be implemented Real Soon Now (TM). Data files are a bit more interesting, and you're the second person to mention having to install data files with the Distutils lately -- so I guess it's a real issue.

So where the heck should they go? The GNU Coding Standards recommend that the directory be called "datadir" (in the Makefile and configure script) and that "datadir" normally map to "$prefix/share", ie. "/usr/local/share". OK, this can be adapted to the Distutils way of thinking about installation easily enough, and on Unix it'll follow the GNU standards. No problem.

But what about Windows and Mac OS? Granted, most people won't be running "setup.py install" -- that's only for people building from source, who will be a small minority on those user-friendly, compiler-challenged platforms. But someone still has to create the binary distribution, which will decided where data files should go. So I guess it doesn't matter that most people won't use the "install" command directly; whoever puts together the binary dist. will use it (or something like it) on their behalf, so whatever the "install" command does will propagate out to the rest of the world.

So how *should* Python module distributions be installed on Windows and Mac OS? OK, modules go right in $prefix (eg. "C:\Program Files\Python" for a typical Python Windows installation) -- but what about scripts, data files, documentation, or whatever else we might end up installing? Should each module distribution get its own directory under $prefix? Other ideas? Perhaps I should wait for feedback until I've written up the Unix installation scheme, but if anyone has firm ideas now, I'd like to hear 'em.

Lastly, we have three modules written in C that need to be compiled plus a C library package that also needs to be compiled. I can set up the include directories and library directories for each platform, but we would like to have a platform-independent script that probes the platform type and checks to see where the include and library files are located and then assigns the include and library directories before the compile and link.

Building C libraries and extensions is handled. *Installing* C libraries is not, just because I didn't think it necessary -- that wouldn't be too hard to change, but let me know if you think it *is* generally necessary.

Probing the system to figure out what needs doing is *not* handled, and will not be handled in Distutils 1.0 unless someone out there gets ambitious and rewrites Autoconf in Python. (I have assumed all along, and repeatedly stated publicly, that I don't think there's any other way to do it. I'm still waiting for someone to contradict me and say, "No no! You're missing this simple, obvious trick that will make it all *easy*!".)

The approach currently taken is to require users to *cough* edit the setup script. Just like the good ol' days before autoconf, when we all edited Makefiles without really understanding what we were doing... (well, *I* didn't understand what I was doing). Distutils 1.0 will have some sort of config file mechanism; hopefully it will be powerful enough that users will just have to edit a config file rather than the setup script.

We want to have a working installation procedure by April 15th.

Then I should stop dealing with this damn mailing list and go write some code!

Greg