[Distutils] thoughts on distutils 1 & 2 (addendum)

[Mark W. Alexander]

On Wed, May 19, 2004 at 11:07:02PM +0100, has wrote:
> Stefan Seefeld wrote:
> >what do you want to reuse that you can't right now ?
> 
> The 'setup.py' [or whatever you want to call it] script. Reduce the 
> amount of code the module developer needs to write. For simple 
> modules and packages, this could (and should) be zero.
[snip]
> My point is that some of this data shouldn't be in the setup scripts, 
> and at least some of the rest should be automatically determined by 
> the system rather than specified by the user (unless they need to 
> override the automatics):

I think, with proper metadata definitions standardized in setup.cfg,
DU could be modified such that:

from distutils import setup
setup()

would simply pull all it's information from the setup.cfg and go. That's
_almost_ zero. I don't think you can get to absolute zero because
somewhere the author has to specify the metadata.

> - Put metadata (by which I mean information describing the 
> module/package itself; its name, version, author, dependencies, etc) 
> into a standard metadata file, e.g. meta.txt, within the package.

That's what setup.cfg is.

> - Put data/code used to build the distro into a build.py script. Put 
> data/code used to install the distro into a install.py script.

Not necessary at all.

> i.e. There should be a clear distinction made between information 
> describing the module and information used merely in 
> building/installing it (custom paths, framework bindings, etc). These 
> are two very different things and should be handled accordingly. 
> [Note: any time I say 'metadata' I'm referring to the former, not the 
> latter.]

That would be nice, but if the package author requires "custom paths,
framework bindings, etc." there's simply no way DU could guess where
those come from so the author has to put them somewhere. The setup.cfg
file (http://python.org/doc/current/dist/setup-config.html) already has
different sections for the build and install metadata _if_ they are
required.

> With DU1, all this data is squidged into setup.py. This is 
> suboptimal: it's not very convenient to read/edit, and there's some 
> unnecessary duplication of metadata occurring over the build/install 
> process as some of this data gets duplicated into PKG-INFO (which'd 
> be unnecessary if it was put into a meta.txt file in the first place).

setup.cfg == meta.txt

The PKG-INFO file (iirc) is a(n extractable) subset of the setup.cfg
metadata brought up in PEP 301 for the purpose of publishing package
information to an "index server". It's not something that should have to
be dealt with manually at all (again assuming we nail the metadata
correctly).

> Often the only unique information stored in setup.py is said 
> 'metadata', which is really a suboptimal arrangement. (Plus stuff 
> like sub-package names, which can and should be gotten rid of in 
> most, if not all, cases.)

setup.py's dist process produces the PKG-INFO file, by combining the
setup.py and setup.cfg metadata, although I'd still prefer to see
setup.cfg be the "authoritative" metadata source so the "almost zero"
setup.py concept would work with the author only having to maintain
metadata in one place. (I think that's the force behind your argument,
correct?)

> Maybe a practical example'd help:

[snip]

I believe almost everything in your example is available through
setup.cfg _today_. Your argument underscores the point that it is
clearly not documented as such. By modifying setup() to search for
any unspecified parameters in setup.cfg (which it almost does now; I
think the only required arg is "name") doesn't that meet your goals?

mwa
-- 
Mark W. Alexander
slash at dotnetslash.net

The contents of this message authored by Mark W. Alexander are
released under the Creative Commons Attribution-NonCommercial license.
Copyright of quoted materials are retained by the original author(s).

http://creativecommons.org/licenses/by-nc/1.0/