[Distutils] Distutil installation tricks

[Greg Ward]

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
-- 
Greg Ward - Unix weenie                                 gward@python.net
http://starship.python.net/~gward/
I'd like some JUNK FOOD ... and then I want to be ALONE --