[Distutils] More documentation for setup meta-data

[M.-A. Lemburg]

Richard Jones wrote:
> On Sat, 1 Mar 2003 11:00 pm, M.-A. Lemburg wrote:
>>>>Perhaps it needs to be renamed to 'download_spec_url'.
>>>
>>>Hurm - we could just accept that a download url with a specific suffix is
>>>a spec (eg. .pkgspec)? We could go as far as say that if it's an XML file
>>>(ie. .xml), then it's a download spec. I'm pre-supposing XML, of course,
>>>when the INI format would probably be enough. Again, I think I'd like to
>>>see some more flesh on your proposal (especially the bits about making it
>>>as simple as possible for the package maintainer) before I jump on the
>>>band-wagon :)
>>
>>Have a look at the ActiveState PPD format (used by their PPM
>>system to find the right download files):
>>
>>"""
>><SOFTPKG NAME="egenix-mx-base" VERSION="2,1,0">
>>         <TITLE>eGenix mx Extensions for Python - Base Distribution</TITLE>
>>         <ABSTRACT>The eGenix mx Extension Series are a collection of
>>Python extensions written in ANSI C and Python
>>which provide a large spectrum of useful additions
>>to everyday Python programming.
>>
>>The Base Distribution includes the Open Source subpackages
>>of the series and is needed by all other add-on
>>packages of the series.
>>
>>This software is brought to you by eGenix.com and
>>distributed under the eGenix.com Public License.
>></ABSTRACT>
>>         <AUTHOR>Marc-Andre Lemburg (mal@egenix.com)</AUTHOR>
>>         <IMPLEMENTATION>
>>                 <PYTHONCORE VERSION="2.1.3" />
>>                 <OS VALUE="linux-i686" />
>>                 <ARCHITECTURE VALUE="i686-linux-thread-multi" />
>>                 <CODEBASE
>>HREF="http://www.egenix.com/files/python/egenix-mx-base-2.1.0.linux-i686.gz
>>tar" /> </IMPLEMENTATION>
>></SOFTPKG>
>>"""
>>
>>I think we can build on that.
> 
> 
> Hopefully by making it significantly simpler. Preferrably with no hand-editing 
> of XML. One of my goals with PyPI registration was to make the operation as 
> simple and transparent as possible.
> 
> Hurm. I suppose the download spec file generation could be automated at the 
> time the dist (either source or binary) file is generated, or perhaps using a 
> switch to the dist command. At a minimum, we could produce a skeleton that 
> the package maintainer needs to edit. Again, not necessarily XML, as that 
> requires - well, editing XML, which I see as an unreasonable barrier to 
> entry.

The above XML-snippet is generated from the meta information
given in the setup.py and the distribution build information
generated by distutils during the bdist_xxx process (note that
this has all the naming information needed including the
possible name extensions added by the package author).

There is no hand-editing of XML required :-) The specification
of alternative download URLs could be made in the setup.py file
as well (or setup.cfg for that matter), including a reference
to the mirror farm if there should ever be one.

Still to do is find a list of aspects which are needed
in order to make automatic binary download selection
robust:

  * Python version string
  * distutils platform string
  * type of bdist/sdist
  * list of external dependencies (these will most likely be lib names
    which distutils can check prior to installation; needs to be
    spec'ed out); alternatively, distutils could do trial-and-error
    here, by calling a predefined command for checking compatibility
    prior to installing the package but after having downloaded it

Anything else ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Mar 01 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford:                                     31 days left
EuroPython 2003, Charleroi, Belgium:                       115 days left