[Sorry, I just noticed that my mailer was auto-setting my send identity to rjones@ekit - which was my email address until yesterday. I've fixed it now. 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 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.
Yep, hence my comment that the download_url and download-mirrors approaches 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 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 for the end user to work with. Well, at least I can't think of a reasonable setup - 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 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 :)