Well, my first real experience with bdist_rpm was last Thursday, putting together the Distutils 0.9 RPM. I also built RPMs for NumPy and mxDateTime just to see if it would work (it did, mostly). Some comments: * is it really necessary to run "build" twice? This takes quite a while with NumPy (with two source files > 600k) on a 100 MHz Pentium, and I don't think it's necessary -- you *should* just be able to ask the "build" command what its outputs would have been with 'get_outputs()' * the .spec file is always generated with "python setup.py ..." commands, even if I ran "/usr/local/bin/python1.6 setup.py ..." to generate the RPM. Thus, if I use a non-standard Python to create the .spec file, it still uses the standard /usr/bin/python, and I end up with an RPM that goes in /usr/lib/python1.5/site-pacakges. I'm not saying that an RPM that installs to /usr/local/lib/python1.6/site-packages is necessarily a good thing to be distributing, but if I use that python to make the RPM... * should we put the output RPMs (source and "binary" -- not really a binary for pure-Python distributions, but you-know-what-I-mean) in a more convenient place? If I didn't know the system intimately, it would not have occurred to me to look for the built RPM in build/bdist.linux2/rpm/RPMS/noarch. ;-) I'm thinking that a common directory for distribution bureaucracy is a good idea, and we already have a start: putting .spec files in "dist" if bdist_rpm is *only* generating the .spec file. So here's a short list of what could go in "dist" right now: - .spec file - RPMs - Win32 exes - source distributions (tarball, zip file) - dumb built distributions (tarball, zip file) Currently, all of these things wind up wherever they feel (mostly in the distribution root, but also a few other places). This just seems like a really good idea to me, so unless anyone howls I'm going to go ahead and implement it. In future, there could be a "debian" subdirectory of "dist", and maybe a directory of FreeBSD "port" info (if that's how it works -- not really clear on that). A Wise script could also go there, if you need to generate a full-blow Windows installer instead of Thomas' minimalist self-extracting ZIP file. Comments? Greg -- Greg Ward - Linux geek gward@python.net http://starship.python.net/~gward/ I'm a nuclear submarine under the polar ice cap and I need a Kleenex!
I checked in a new version of setup.py for Numerical that corresponds to Distutils-0.9. This is a modification of the setup_numpy.py that Greg has in Distutils. This version REQUIRES the new Distutils. If you install Distutils into 1.6a2, remember (which I didn't at first) to go delete the distutils directory in the Python library directory. If you don't you will get a message while running setup informing you that your Distutils must be updated. This CVS version also separates out LAPACK/BLAS so that using the "lite" version of the libraries supplied with numpy is now optional. A small attempt is made to find the library or the user can edit setup.py to set the locations if that fails. I have not tested this on Windows and I would bet it needs help; we probably won't cut a new Numerical release until this is resolved and Python 2.0 is out so that the needed version of Distutils is standard. Suggestions for improvements would be most welcome. Paul
On 06 July 2000, Paul F. Dubois said:
This version REQUIRES the new Distutils. If you install Distutils into 1.6a2, remember (which I didn't at first) to go delete the distutils directory in the Python library directory. If you don't you will get a message while running setup informing you that your Distutils must be updated.
The "Official Recommendation" is just to rename that directory away: that way you'll have (eg.) lib/python1.6/distutils-orig and lib/python1.6/site-packages/distutils, and the site-packages version will take precedence without having clobbered the standard library too badly. See the Distutils README.txt. The alternative was support in the Distutils for replacing/upgrading bits of the standard library; Guido was, shall we say, non-receptive to that idea. Oh well.
This CVS version also separates out LAPACK/BLAS so that using the "lite" version of the libraries supplied with numpy is now optional. A small attempt is made to find the library or the user can edit setup.py to set the locations if that fails.
Oh good, does that mean it'll take less than 20 minutes to compile NumPy on my pokey old 100 MHz Pentium? ;-) Greg -- Greg Ward - Unix bigot gward@python.net http://starship.python.net/~gward/ Software patents SUCK -- boycott amazon.com!
participants (2)
-
Greg Ward -
Paul F. Dubois