[Distutils] Pondering multi-package packages

[Greg Ward]

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!