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.
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:
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?