Richard Jones wrote:
On Sat, 1 Mar 2003 11:00 pm, M.-A. Lemburg wrote:
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 (mal@egenix.com)</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.
The above XML-snippet is generated from the meta information given in the setup.py and the distribution build information generated by distutils during the bdist_xxx process (note that this has all the naming information needed including the possible name extensions added by the package author). There is no hand-editing of XML required :-) The specification of alternative download URLs could be made in the setup.py file as well (or setup.cfg for that matter), including a reference to the mirror farm if there should ever be one. Still to do is find a list of aspects which are needed in order to make automatic binary download selection robust: * Python version string * distutils platform string * type of bdist/sdist * list of external dependencies (these will most likely be lib names which distutils can check prior to installation; needs to be spec'ed out); alternatively, distutils could do trial-and-error here, by calling a predefined command for checking compatibility prior to installing the package but after having downloaded it Anything else ? -- 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