Hi all --
I've just checked in the beginnings of support for creating "built distributions" (aka binary distributions, but of course they aren't necessarily binary -- you might want to distribute something that is immediately installable but contains only Python code).
This consists of two commands so far, 'bdist' and 'bdist_dumb'. These follow the model of the 'build' and 'install' families, where there is one high-level coordinator, and "sub-commands" that do the real work. So far, obviously, there's only one bdist sub-command, and all it creates are "dumb" built distributions -- tarballs and zip files that you unpack from <prefix> or <exec-prefix>.
There are a number of obvious weaknesses to this, but this was intended more as a warm-up exercise than the real thing. First of all, the end user has to somehow know to chdir to Python's <prefix> or <exec-prefix> and unpack the dumb distribution there. Worse, they have to know to sometimes chdir to to <prefix>, and sometimes <exec-prefix> -- assuming there's even a difference on their system. Anyways, as I said, this is not the be-all, end-all to creating built Python module distributions! However, it's all that I could whip up in three evenings.
If you'd like to try it out, please do! Here's the basic idea:
python setup.py bdist
or: python setup.py bdist --formats=gztar # or zip, tar, or ztar
The default format is currently gztar for Unix, zip for Windows. Obviously, that will have to get a bit more complicated: we'll want to create an RPM on RPM-based systems, a Debian package on Debian systems, a BSD package on BSD systems, some sort of executable installer (probably Wise) on Windows systems, etc. But for now, you get either a tarball or a zipfile, and if you don't specify --formats, you get whatever is sensible on your current OS.
For example, if I go to my NumPy 15.2 directory (which is identical to the NumPy 15.2 distribution, except I use the example NumPy setup script included with the Distutils!) and run this:
$ python setup.py bdist
then I get (roughly) this output:
[...build output omitted...] creating build/bdist creating build/bdist/lib creating build/bdist/lib/python1.5 creating build/bdist/lib/python1.5/site-packages creating build/bdist/lib/python1.5/site-packages/Numeric hard linking build/lib.linux-i586/ArrayPrinter.py -> build/bdist/lib/python1.5/site-packages/Numeric hard linking build/lib.linux-i586/FFT.py -> build/bdist/lib/python1.5/site-packages/Numeric [...and so on, for all modules that NumPy would install...] changing into 'build/bdist' tar -cf /scratch/python/Numerical-15.2/Numerical-15.2.linux-i586.tar . gzip /scratch/python/Numerical-15.2/Numerical-15.2.linux-i586.tar changing back to '/scratch/python/Numerical-15.2'
and the resulting tarball, Numerical-15.2.linux-i586.tar.gz, looks like this:
$ tar tzf Numerical-15.2.linux-i586.tar.gz ./ lib/ lib/python1.5/ lib/python1.5/site-packages/ lib/python1.5/site-packages/Numeric/ lib/python1.5/site-packages/Numeric/ArrayPrinter.py lib/python1.5/site-packages/Numeric/FFT.py lib/python1.5/site-packages/Numeric/LinearAlgebra.py [...] lib/python1.5/site-packages/Numeric/ranlib.so lib/python1.5/site-packages/Numeric/arrayfns.so
which reduces installing Numerical Python to a mere
python -c "import sys; print sys.exec_prefix"
$ tar xzvf /scratch/python/Numerical-15.2/Numerical-15.2.linux-i586.tar.gz
OK, OK, so it's not immediately obvious that this is better than a simple "python setup.py install". ;-) But think of the possibilities!
Feel free to add to this list...
-- Greg Ward - just another /P(erl|ython)/ hacker email@example.com http://starship.python.net/~gward/ If it can't be expressed in figures, it is not science--it is opinion.