[Distutils] More documentation for setup meta-data

[M.-A. Lemburg]

Richard Jones wrote:
> [cc'ed only to distutils now]
>>>Note that I would like to see an alternative system that is used to
>>>disseminate packages which uses a set of mirrors similar to CPAN. There's
>>>an accepted naming system so that the package may be found just using the
>>>package name and version, and a fatch command that attempts to download
>>>the package from one or more of the mirrors (depending on availability).
>>>PyPI then supplies a list of the mirror sites. Distutils may also offer
>>>an upload command, to make life even easier for the package maintainer.
>>>No need to maintain download urls or even download sites. The kicker with
>>>this plan is the provision of the bandwidth. The other elements of it are
>>>... well, trivial. They could be implemented before 2.3 is released.
>>
>>If you intend to use the download_url for this purpose, then
>>you ought to reserve it's usage for this now. Otherwise,
>>people will simply put a link to the download web-site
>>into this field.
> 
> I think that the download_url and download-mirrors approaches are quite 
> independant. I guess though that download_url would specify a directory, not 
> a file. That would then fit in with the above scheme. Then users wouldn't 
> necessarily have to upload their package to the network-of-mirrors.

The download mirrors idea is fine, but it may not always be
what package authors want to use, e.g. companies selling Python
products may want to have complete control over the sites where
you can download their code. The same is true for touchy things
like crypto code.

Even with the mirror idea you still need to tell the system which
files have been uploaded and for which platforms these
are intended (note that not all package authors use the
default distutils naming scheme for files).

The idea with a central download file specification would
solve all of these problems by being explicit about the
names and locations. You only need one URL for this file
and that's why I proposed to use the download_url for this.

Perhaps it needs to be renamed to 'download_spec_url'.

> I'm between jobs at the moment, and have unsubscribed from python-list. Would 
> someone else like to ask there for offers of mirror space? Just so we can see 
> how viable the approach is? I don't believe that creosote will be useful 
> (from what people have said in passing) - but that's ok. I'm not completely 
> up to speed with mirroring - can it be done in such a way that there's no 
> central "master" server? Or will we have to nominate one?

Why start with a complicated system ? IMHO, it's much better
first getting the already not very easy task of finding
the right download URL in place. Then you can automate this
by setting up a server system and point the download_spec_url
to that server (which then takes over management of the
entries in whatever method is needed).

-- 
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