[Distutils] More documentation for setup meta-data

[Richard Jones]

[cc'ed only to distutils now]

On Sat, 1 Mar 2003 03:22 am, M.-A. Lemburg wrote:
> Richard Jones wrote:
> > On Thu, 27 Feb 2003 7:25 pm, M.-A. Lemburg wrote:
> >>Richard Jones wrote:
> >>>I'm trying to better document the meta-data for the distutils (and hen=
ce
> >>>PyPI). I've added words to the section in the dev doc about meta-data,
> >>>and would like some feedback before I post the patch to be applied.
> >>>Sorry, it's in LaTeX form (until someone writes the ReST->python doc
> >>>converter ;)
> >>>
> >>>  \lineiii{download_url}{a location where the package may be
> >>>downloaded}{URL}{(3)}
> >>>  \lineiii{classifiers}{a list of Trove classifiers}{list of
> >>>strings}{(3)} \end{tableiii}
> >>
> >>download_url is not a valid Distribution option (even though it
> >>is listed in the DistributionMetaData). I wonder why you mention
> >>it here.
> >
> > It is new in 2.3
>
> Uhm, it doesn't work in Python 2.3... that's why I was asking.

Hurm, that's odd. I thought the patch had been applied. I guess it hasn't=20
(it's not mine, so I don't pay close attention to it)...


> > 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 t=
he
> > 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 wi=
th
> > this plan is the provision of the bandwidth. The other elements of it a=
re
> > ... 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=20
independant. I guess though that download_url would specify a directory, no=
t=20
a file. That would then fit in with the above scheme. Then users wouldn't=20
necessarily have to upload their package to the network-of-mirrors.

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


    Richard