[Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
Mon, 19 Mar 2001 23:49:33 -0700
Here is PEP 243, discussing how to make Distutils submit .tar.gz
packages (and the like) to the mythical catalog server. I've got code for
this prototyped, but give me a couple of days to make it completely
Moshe has already commented:
a. you don't say which URL to post to (just spell it out:
POST http://modules.python.org:80/ (and let upload override that)
b. have the codes be HTTP codes and the headers HTTP non-standard
(X-) headers. how about using the HTTP headers and error-codes, and
have *all* the page human readable.
Good comments, I'll look at building them in...
I look forward to any comments -- I'd like to start working on distutils
patches within the week.
Title: Module Repository Upload Mechanism
Author: firstname.lastname@example.org (Sean Reifschneider)
Type: Standards Track
For a module repository system (such as Perl's CPAN) to be
successful, it must be as easy as possible for module authors to
submit their work. An obvious place for this submit to happen is
in the Distutils tools after the distribution archive has been
successfully created. For example, after a module author has
tested their software (verifying the results of "setup.py sdist"),
they might type "setup.py sdist --submit". This would flag
Distutils to submit the source distribution to the archive server
for inclusion and distribution to the mirrors.
This PEP only deals with the mechanism for submitting the software
distributions to the archive, and does not deal with the actual
The upload will include the Distutils "PKG-INFO" meta-data
information (as specified in PEP-241 ), the actual software
distribution, and other optional information. This information
will be uploaded as a multi-part form encoded the same as a
regular HTML file upload request. This form is posted using
The upload will be made to the host "modules.python.org" on port
80/tcp. The form will consist of the following fields:
distribution -- The file containing the module software (for
example, a .tar.gz or .zip file).
distmd5sum -- The MD5 hash of the uploaded distribution,
encoded in ASCII representing the hexadecimal representation
of the digest ("for byte in digest: s = s + ('%02x' %
pkginfo -- The file containing the distribution meta-data (as
specified in PEP-241 ).
infomd5sum -- The MD5 hash of the uploaded meta-data, encoded
in ASCII representing the hexadecimal representation of the
digest ("for byte in digest: s = s + ('%02x' % ord(byte))").
platform (optional) -- A string representing the target
platform for this distribution. This is only for binary
distributions. It is encoded as
signature (optional) -- A GPG signature of the uploaded
distribution as signed by the author. This may be used by the
cataloging system to automate acceptance of uploads.
The upload will report the status of the upload by sending the
string "Upload status:" followed by one of the following:
SUCCESS -- Indicates that the upload has succeeded.
FAILURE -- The upload is, for some reason, unable to be
TRYAGAIN -- The server is unable to accept the upload at this
time, but the client should try again at a later time.
Potential causes of this are resource shortages on the server,
administrative down-time, etc...
Following the above string may be a human-readable string
providing further information. This message continues to the end
of the returned data-stream.
Returned data which does not fit the above format should be
treated as a temporary failure.
The upload client must submit the page in the same form as
Netscape Navigator version 4.76 for Linux produces when presented
with the following form:
<FORM NAME="fileupload" METHOD="POST" ACTION="swalowpost.cgi"
<INPUT TYPE="file" NAME="distribution"><BR>
<INPUT TYPE="text" NAME="distmd5sum"><BR>
<INPUT TYPE="file" NAME="pkginfo"><BR>
<INPUT TYPE="text" NAME="infomd5sum"><BR>
<INPUT TYPE="text" NAME="platform"><BR>
<INPUT TYPE="text" NAME="signature"><BR>
<INPUT TYPE="SUBMIT" VALUE="Upload">
The following are valid os names:
The above include a number of different types of distributions of
Linux. Because of versioning issues these must be split out, and
it is expected that when it makes sense for one system to use
distributions made on other similar systems, the download client
will make the distinction.
Version is the official version string specified by the vendor for
the particular release. For example, "nt" (Windows), "9.04"
(HP-UX), "7.0" (RedHat, Mandrake).
The following are valid architectures:
I currently have a proof-of-concept client and server implemented.
I plan to have the Distutils patches ready for the 2.1 release.
Combined with Andrew's PEP-241  for specifying distribution
meta-data, I hope to have a platform which will allow us to gather
real-world data for finalizing the catalog system for the 2.2
 Metadata for Python Software Package, Kuchling,
This document has been placed in the public domain.
I used to think that the brain was the most wonderful organ in
my body. Then I realized who was telling me this. -- Emo Phillips
Sean Reifschneider, Inimitably Superfluous <email@example.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python