More documentation for setup meta-data

I'm trying to better document the meta-data for the distutils (and hence PyPI). I've added words to the section in the dev doc about meta-data, and would like some feedback before I post the patch to be applied. Sorry, it's in LaTeX form (until someone writes the ReST->python doc converter ;) \subsection{Additional meta-data} \label{meta-data} The setup script may include additional meta-data beyond the name and version. This information includes: \begin{tableiii}{l|l|l|c}{code}% {Meta-Data}{Description}{Value}{Notes} \lineiii{name}{the name of the package}{short string}{(1)} \lineiii{version}{the version of this release}{short string}{(1)(4)} \lineiii{author}{package author's name}{short string}{(2)} \lineiii{author_email}{email address of the package author}{email address}{(2)} \lineiii{maintainer}{package maintainer's name}{short string}{(2)} \lineiii{maintainer_email}{email address of the package maintainer}{email address}{(2)} \lineiii{home_page}{the location of the homepage for the package}{URL}{(1)} \lineiii{description}{a short, summary description of the package}{short string}{} \lineiii{long_description}{a longer description of the package}{long string}{} \lineiii{download_url}{a location where the package may be downloaded}{URL}{(3)} \lineiii{classifiers}{a list of Trove classifiers}{list of strings}{(3)} \end{tableiii} \noindent Notes: \begin{description} \item[(1)] these fields are required \item[(2)] either the author or the maintainer must be nominated \item[(3)] should not be used if your package is to be compatible with Python versions prior to 2.2.3 or 2.3. The list is available from the PyPI website. \item[(4)] it is recommended that versions take the form <major>.<minor>.<patch>[.<sub>] \item["short string"] a single line of text, not more than 200 characters \item["long string"] multiple lines of text \item["list of strings"] see below \end{description} \option{version} encoding is an art in itself. Python packages generally adhere to the version format \em{major.minor.patch}. The major number is 0 for initial, experimental releases of software. It is incremented for releases that represent major milestones in a package. The minor number is incremented when important new features are added to the package. The patch number increments when bug-fix releases are made. Additional trailing version information is sometimes used to indicate sub-releases. These are "a1,a2,...,aN" (for alpha releases, where functionality and API may change), "b1,b2,...,bN" (for beta releases, which only fix bugs) and "pr1,pr2,...,prN" (for final pre-release release testing). Some examples: \begin{description} \item[0.1.0] the first, experimental release of a package \item[1.0.1a2] the second alpha release of the first patch version of 1.0 \end{description} \option{classifiers} are specified in a python list: \begin{verbatim} setup(... classifiers = [ 'Development Status :: 4 - Beta', 'Environment :: Console', 'Environment :: Web Environment', 'Intended Audience :: End Users/Desktop', 'Intended Audience :: Developers', 'Intended Audience :: System Administrators', 'License :: OSI Approved :: Python Software Foundation License', 'Operating System :: MacOS :: MacOS X', 'Operating System :: Microsoft :: Windows', 'Operating System :: POSIX', 'Programming Language :: Python', 'Topic :: Communications :: Email', 'Topic :: Office/Business', 'Topic :: Software Development :: Bug Tracking', ], ... ) \end{verbatim} If you wish to include classifiers in your \file{setup.py} file and also wish to remain backwards-compatible with Python releases prior to 2.2.3, then you can include the following code fragment in your \file{setup.py} before the \code{setup()} call. \begin{verbatim} # patch distutils if it can't cope with the "classifiers" or # "download_url" keywords if sys.version < '2.2.3': from distutils.dist import DistributionMetadata DistributionMetadata.classifiers = None DistributionMetadata.download_url = None \end{verbatim}

Richard Jones wrote:
download_url is not a valid Distribution option (even though it is listed in the DistributionMetaData). I wonder why you mention it here. The concept of a single URL for downloads seems to simplistic to handle the issues involved with automatic installation. This information should also be provided in a lazy way, so that the package author can easily update the download links, e.g. by placing the information in an XML file on his site and then referencing this file in the distutils meta data. The file should then be parsed by a distutils subcommand to find the right download URL depending on the platform and Python version. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 27 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: 33 days left EuroPython 2003, Charleroi, Belgium: 117 days left

On Thu, 27 Feb 2003 7:25 pm, M.-A. Lemburg wrote:
It is new in 2.3
This system sounds quite useful and flexible. It could also get very complicated, very quickly (for a package maintainer). The download_url may still be used for this purpose if it specifies a metadata file as the download. On the other hand, Anthony Baxter has written a distutils command that will download a specified package and install it. This was recently posted to distutils-sig "first cut at a distutils 'fetch' command". Sure, it's not an optimal solution - in the same way that PyPI is going to need tweaking over time once it's actually used. It's a start though. 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. Richard

[Richard Jones Fri, Feb 28, 2003 at 08:51:51AM +1100]
Maybe asking c.l.py subscribers for servers (with bandwidth) as mirrors for such a project would help. After all, python distutils-packages are usually not that big. And many people are longing for a way to upload/download packages semi-automatically. holger

Richard Jones wrote:
Uhm, it doesn't work in Python 2.3... that's why I was asking.
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. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left

[cc'ed only to distutils now] On Sat, 1 Mar 2003 03:22 am, M.-A. Lemburg wrote:
Hurm, that's odd. I thought the patch had been applied. I guess it hasn't (it's not mine, so I don't pay close attention to it)...
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. 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? Richard

On Sat, Mar 01, 2003 at 10:34:58AM +1100, Richard Jones wrote:
Huh? I thought I checked all the relevant bits in before 2.3alpha2, and it seems to work for me. (It wasn't in 2.3alpha1.) MAL, when you say "it doesn't work", what do you mean? --amk (www.amk.ca) Good place to put things, cellars. -- The Doctor, in "Remembrance of the Daleks"

A.M. Kuchling wrote:
Well, if you pass download_url="something" to setup() then you get an error saying that this is an unknown parameter. Unless I have misunderstood something, that was the intended purpose of download_url, right ? (and it should then end up in the meta information just like the classifiers) -- 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

On Sat, Mar 01, 2003 at 11:05:56AM +0100, M.-A. Lemburg wrote:
Well, if you pass download_url="something" to setup() then you get an error saying that this is an unknown parameter.
Please file a bug on SF, including a transcript and the problematic setup.py file. (Or post it here.) This certainly works for me currently. --amk (www.amk.ca) I'm not going to sit here like a spare lemon waiting for the squeezer. -- The Brigadier, in "The Daemons"

A.M. Kuchling wrote:
Oops. Sorry; I tried in a shell window which did not have PYTHONPATH set to point to the CVS distutils version. If I retry this now with properly adjusted PYTHONPATH this does work. -- 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

Richard Jones wrote:
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'.
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

[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:
Yep, hence my comment that the download_url and download-mirrors approaches are quite independant.
I think this could be worked around by having the file submission mechanism force the filename to follow a specific pattern.
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 :) Richard

Richard Jones wrote:
You can do that for the mirror type approach, but certainly not for the download_spec_url approach. While distutils already goes a long way in trying to add enough information to the filename to be able to identify the right one to download, this is sometimes not enough, e.g. RPM names do not include the Python version per default, or you may want to add a OS specific tag to the name (like "suse_8.rpm"). The specification file would make this information machine readable and thus enable a download mechanism to choose the right version for download.
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).
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.gztar" /> </IMPLEMENTATION> </SOFTPKG> """ I think we can build on that. -- 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

On Sat, 1 Mar 2003 11:00 pm, M.-A. Lemburg wrote:
Sorry, I wasn't clear. The end user I was referring to was the package maintainer. We discuss this below though...
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. Richard

Richard Jones wrote:
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

Richard Jones wrote:
download_url is not a valid Distribution option (even though it is listed in the DistributionMetaData). I wonder why you mention it here. The concept of a single URL for downloads seems to simplistic to handle the issues involved with automatic installation. This information should also be provided in a lazy way, so that the package author can easily update the download links, e.g. by placing the information in an XML file on his site and then referencing this file in the distutils meta data. The file should then be parsed by a distutils subcommand to find the right download URL depending on the platform and Python version. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 27 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: 33 days left EuroPython 2003, Charleroi, Belgium: 117 days left

On Thu, 27 Feb 2003 7:25 pm, M.-A. Lemburg wrote:
It is new in 2.3
This system sounds quite useful and flexible. It could also get very complicated, very quickly (for a package maintainer). The download_url may still be used for this purpose if it specifies a metadata file as the download. On the other hand, Anthony Baxter has written a distutils command that will download a specified package and install it. This was recently posted to distutils-sig "first cut at a distutils 'fetch' command". Sure, it's not an optimal solution - in the same way that PyPI is going to need tweaking over time once it's actually used. It's a start though. 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. Richard

[Richard Jones Fri, Feb 28, 2003 at 08:51:51AM +1100]
Maybe asking c.l.py subscribers for servers (with bandwidth) as mirrors for such a project would help. After all, python distutils-packages are usually not that big. And many people are longing for a way to upload/download packages semi-automatically. holger

Richard Jones wrote:
Uhm, it doesn't work in Python 2.3... that's why I was asking.
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. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left

[cc'ed only to distutils now] On Sat, 1 Mar 2003 03:22 am, M.-A. Lemburg wrote:
Hurm, that's odd. I thought the patch had been applied. I guess it hasn't (it's not mine, so I don't pay close attention to it)...
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. 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? Richard

On Sat, Mar 01, 2003 at 10:34:58AM +1100, Richard Jones wrote:
Huh? I thought I checked all the relevant bits in before 2.3alpha2, and it seems to work for me. (It wasn't in 2.3alpha1.) MAL, when you say "it doesn't work", what do you mean? --amk (www.amk.ca) Good place to put things, cellars. -- The Doctor, in "Remembrance of the Daleks"

A.M. Kuchling wrote:
Well, if you pass download_url="something" to setup() then you get an error saying that this is an unknown parameter. Unless I have misunderstood something, that was the intended purpose of download_url, right ? (and it should then end up in the meta information just like the classifiers) -- 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

On Sat, Mar 01, 2003 at 11:05:56AM +0100, M.-A. Lemburg wrote:
Well, if you pass download_url="something" to setup() then you get an error saying that this is an unknown parameter.
Please file a bug on SF, including a transcript and the problematic setup.py file. (Or post it here.) This certainly works for me currently. --amk (www.amk.ca) I'm not going to sit here like a spare lemon waiting for the squeezer. -- The Brigadier, in "The Daemons"

A.M. Kuchling wrote:
Oops. Sorry; I tried in a shell window which did not have PYTHONPATH set to point to the CVS distutils version. If I retry this now with properly adjusted PYTHONPATH this does work. -- 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

Richard Jones wrote:
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'.
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

[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:
Yep, hence my comment that the download_url and download-mirrors approaches are quite independant.
I think this could be worked around by having the file submission mechanism force the filename to follow a specific pattern.
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 :) Richard

Richard Jones wrote:
You can do that for the mirror type approach, but certainly not for the download_spec_url approach. While distutils already goes a long way in trying to add enough information to the filename to be able to identify the right one to download, this is sometimes not enough, e.g. RPM names do not include the Python version per default, or you may want to add a OS specific tag to the name (like "suse_8.rpm"). The specification file would make this information machine readable and thus enable a download mechanism to choose the right version for download.
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).
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.gztar" /> </IMPLEMENTATION> </SOFTPKG> """ I think we can build on that. -- 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

On Sat, 1 Mar 2003 11:00 pm, M.-A. Lemburg wrote:
Sorry, I wasn't clear. The end user I was referring to was the package maintainer. We discuss this below though...
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. Richard

Richard Jones wrote:
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
participants (5)
-
A.M. Kuchling
-
holger krekel
-
M.-A. Lemburg
-
Richard Jones
-
Richard Jones