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