Greg Ward wrote:
[Marc-Andre wants pre- and post-install hooks]
I'd suggest to have setup.py include a reference to two functions somewhere (probably in the setup constructor): one to run for pre-install and one for post-install.
[Harry Henry Gebel points out Distutils' extensibility mechanism]
You can do this now by defining your own install command in setup, I am providing my own build command in PyNcurses to perform some pre-build actions.
[Marc-Andre thinks otherwise]
I'd rather like to see predefined hooks for this than having to define my own install command.
There are two meanings to "install", and I think each of you is talking about a different one. I believe MAL wants to supply pre-install and post-install hooks that would run when someone installs from (eg.) an RPM or executable installer -- ie. from a smart built distribution that has support for {pre,post}-install hooks.
Hmm, the pre/post-install hooks are definitely an install thing. We'd also need a pre-build, though, for the things I mentioned below, e.g. finding header files and libs, checking the compiler, etc.
Harry was talking about overriding the Distutils "install" command, which is fine as long as people only build and install from source. They don't. If you define {pre,post}-install by defining your own "install" command, then they will run on the packager's system, might take effect in the packager's build/bdist.<plat>/<format> directory, and might be propagated to the end-user's machine. But if you tweak the Windows registry, or add a user to /etc/passwd, or what-have-you, then it only affects the packager's machine. Not good.
We need a way for module developers to supply a snippet (or a pile) of Python code that is carried along for the ride when a packager creates a smart built distribution (RPM, wininst, Wise, .deb, whatever) and executed when the installer installs from the smart built distribution. It's OK to write these hooks in Python, because of course there's a Python interpreter on the other end. It should be possibly to write completely portable hooks, but I imagine most such real-world hooks would look like this:
if os.name == "posix": # poke around /lib, frob something in /etc, ... elif os.name == "nt": # twiddle the registry, check for some DLL, ... else: raise RuntimeError, \ "don't know how to install on platform '%s'" % os.name
which in many cases is the Distutils approach to portability. Some of those if/elif/.../else constructs have grown "mac" branches, but not all yet.
These install hooks should be run by the "install" command if this is a "real" installation, but not if it's a "fake" installation done on behalf of one of the "bdist" commands to a temp directory.
Anyone got ideas for a good interface? Function, class, module, chunk of source code as text, or what?
Why not add some keywords to the constructor ?! import mx.ODBC.Misc.DistSupport setup( preinstall = mx.ODBC.Misc.DistSupport.preinstall, postinstall = ...postinstall, prebuild = ...prebuild, postbuild = ...postbuild )
BTW, how can I add some Q&A style setup dialog to build and install commands ?
I will need this for mxODBC since there are plenty subpackages which can all be installed separately and each of them will need to know where to find the header files and libs to link against.
Oops, this reminds me of the part of config files that I forgot to implement: custom configuration information for the current distribution. The idea is that users would edit setup.cfg to provide things like library search paths here. IMHO that's preferable to an interactive build process, but only slightly.
A config file is fine too, but given that someone may want to write an installer, I think we'd also need an API hook for this.
mxDateTime has a different need, which I'm not really sure how to handle: it needs some sort of "try to compile this and return the exit code from the compiler" + "if this compiles, run the result and return the exit code" to be able to define symbols such as HAVE_TIMEGM (much like autoconf does on Unix).
Is this possible with the current distutils ?
No. I've been putting that off as long as possible, because I fear it's a huge job. It basically means rewriting Autoconf in Python. The good news is, no M4 or shell scripts; the bad news is, it has to be insanely portable. (The CCompiler framework should help enormously here, but even so...)
Naa... no need to rewrite Autoconf in Python: the simple tests can easily be done using a few lines of Python provided that the compiler classes allow these trial-and-error approaches.
And a final question: do I have to redistribute distutils together with the mx packages in order to make sure that the build and install process works ? What about 1.5.2 compatibility ?
All versions of the Distutils will work with Python 1.5.2, at least until Python 1.5.2 is as dead as Python 1.4 is today. The basic idea is this: if someone wants to build from source, they either have to be running Python 1.6, or they have to download and install Distutils to their Python 1.5.2 installation.
I will write up an exemplary blurb and put it in the "Distributing Python Modules" documentation -- most programmers seem to have a hard time expressing themselves clearly in README files, and this particular concept must be made loud and clear in every README for every Python module distribution.
Incidentally, I have not had a single complaint of Python 1.5.1 incompatibility since March, when I released Distutils 0.1.4 and 0.1.5 expressly for Python 1.5.1 compatibility. I have not ported those changes forward to the current Distutils, have very little desire to do so, and have seen no reason to do so -- ie. no complaints from users. So does anyone care if I drop my goal of Python 1.5.1 compatibility? (Hey, there's always Distutils 0.1.5 for the Python 1.5.1 crowd...)
1.5.2 is fine with me. By the time I'll push out my new stuff, 1.6 will be out anyway... so 1.5.1 is not much of a problem anymore (I will keep the current Makefile.pre.in +Setup approach for a while too). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/