On 31 May 2000, M.-A. Lemburg said:
Why not ? The RPMs could use the existing Python installation which comes with a version of distutils (at least for 1.6) or use a copy which gets installed together with the package. The post-install script could then pass control to distutils and let it apply its magic.
True when installing and RPM into a Python 1.6 installation, but it'll be a good while before we can assume that. I want Distutils-generated RPMs to work with any version of Python that the modules-being-installed work with. (Granted, you may have to build extensions multiple times for eg. 1.5 and 1.6. But you shouldn't need to have anything more than Python installed to install Python modules from an RPM; the same goes for other built distribution formats.) Also, even when we *can* assume that, we won't be including the setup script in the (binary) RPM (or whatever). So while we could still use the many useful utility functions provided by distutils.*_util, we can't make use of whatever goodies the developer has put in his setup script, like the name of the distribution or the modules it installs.
Hmm, I still don't see why you can't add attribute access methods which check and possibly control the forementioned problems. A few .set_this() and .get_that() methods would make the interface more transparent, add documentation (by virtue of __doc__ strings ;-) and could add check assertions. [...] Why not let the .set_this() method take care of getting the state right ? (or raise an exception if that's impossible) [...] In my experience, it's always better to define object access via methods rather than attributes. This is especially true when the projects evolves with time: you simply forget about the details, side-effects, assertions you made months ago (and possibly forgot to document) about the specific attributes.
I'm moving in the direction of more bureaucracy for command options. We're a long way from "out-of-control", but the system has grown considerably in the last couple of months. There are dependencies and interactions between commands that are only documented in code, default values, type/syntax expectations -- all sorts of things that might be better off under a more bondage 'n discipline regime. One aspect of that regime would be automatic accessor and modifier methods provided by the Command class. However, this is not a high priority for Distutils 1.0. For now, I'm more interested in solving the problem of building, installing, and distributing Python module distributions; I'm inclined to worry about imposing more bureaucracy on the Distutils inner workings in the future. Greg -- Greg Ward - Unix nerd gward@python.net http://starship.python.net/~gward/ Hand me a pair of leather pants and a CASIO keyboard -- I'm living for today!