[Distutils] More documentation for setup meta-data

Richard Jones richardjones@optushome.com.au
Sat Mar 1 05:52:02 2003


[Sorry, I just noticed that my mailer was auto-setting my send identity to=
=20
rjones@ekit - which was my email address until yesterday. I've fixed it now=
=2E=20
My apologies to anyone who received a bounce message!]

On Sat, 1 Mar 2003 09:20 pm, M.-A. Lemburg wrote:
> 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 ju=
st
> >>> 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. Distuti=
ls
> >>> 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. T=
he
> >>> 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.

Yep, hence my comment that the download_url and download-mirrors approaches=
=20
are quite independant.


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

I think this could be worked around by having the file submission mechanism=
=20
force the filename to follow a specific pattern.


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

My argument is that the download file spec system would be quite complex fo=
r=20
the end user to work with. Well, at least I can't think of a reasonable set=
up=20
=2D but perhaps you have :)


> 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=
=20
spec (eg. .pkgspec)? We could go as far as say that if it's an XML file (ie=
=2E=20
=2Exml), then it's a download spec. I'm pre-supposing XML, of course, when =
the=20
INI format would probably be enough. Again, I think I'd like to see some mo=
re=20
flesh on your proposal (especially the bits about making it as simple as=20
possible for the package maintainer) before I jump on the band-wagon :)


     Richard