On Sat, 1 Mar 2003 11:00 pm, M.-A. Lemburg wrote:
Richard Jones wrote:
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 :)
Not at all: by letting the distutils command read the spec file, it can make most if not all decisions automatically.
In the end, the end user will just issue:
python pypi.py install pyxml
and the system will do the rest (talk to the PyPI server, fetch the download spec, identify the right download URL, find a usable mirror, download the prebuilt binary distribution and install it).
Sorry, I wasn't clear. The end user I was referring to was the package maintainer. We discuss this below though...
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 :)
Have a look at the ActiveState PPD format (used by their PPM system to find the right download files):
<SOFTPKG NAME="egenix-mx-base" VERSION="2,1,0"> <TITLE>eGenix mx Extensions for Python - Base Distribution</TITLE> <ABSTRACT>The eGenix mx Extension Series are a collection of Python extensions written in ANSI C and Python which provide a large spectrum of useful additions to everyday Python programming.
The Base Distribution includes the Open Source subpackages of the series and is needed by all other add-on packages of the series.
This software is brought to you by eGenix.com and distributed under the eGenix.com Public License.
</ABSTRACT> <AUTHOR>Marc-Andre Lemburg (firstname.lastname@example.org)</AUTHOR> <IMPLEMENTATION> <PYTHONCORE VERSION="2.1.3" /> <OS VALUE="linux-i686" /> <ARCHITECTURE VALUE="i686-linux-thread-multi" /> <CODEBASE HREF="http://www.egenix.com/files/python/egenix-mx-base-2.1.0.linux-i686.gz tar" /> </IMPLEMENTATION> </SOFTPKG> """
I think we can build on that.
Hopefully by making it significantly simpler. Preferrably with no hand-editing of XML. One of my goals with PyPI registration was to make the operation as simple and transparent as possible.
Hurm. I suppose the download spec file generation could be automated at the time the dist (either source or binary) file is generated, or perhaps using a switch to the dist command. At a minimum, we could produce a skeleton that the package maintainer needs to edit. Again, not necessarily XML, as that requires - well, editing XML, which I see as an unreasonable barrier to entry.