From fgranger@altern.org Sat Mar 10 18:22:26 2001
From: fgranger@altern.org (Francois Granger)
Date: Sat, 10 Mar 2001 19:22:26 +0100
Subject: [Catalog-sig] For french Pythoneers
Message-ID: <v04210111b6d0212b4498@[213.228.24.170]>
Sorry for this message in french. There is a UsenetFR vote on
creating the newsgroup fr.comp.lang.python. And I feel important to
get as many french pytoneer as possible to vote for this.
Le premier appel à voter pour la création d'un groupe de discussion
sur Python est paru.
Allez dans et cherchez le message dont le sujet est :
[AAV 1] Creation de fr.comp.lang.python (non-modere)
Message-ID: <1epxces.18yyneu19bvnu0N%massiot@via.ecp.fr>
et votez ;-)
PS: "Votez OUI, votez NON mais votez"
PPS: "Je vous parle d'un temps / Que les moins de vingt ans / Ne
peuvent pas connaitre..."
;-)
--
"Faites des phrases courtes. Un sujet, un verbe, un complément. Quand
vous voudrez ajouter un adjectif, vous viendrez me voir." - Georges
Clemenceau, 1841-1929, médecin et homme politique français. Consignes
aux journalistes de "L'Aurore". d'après
<http://www.sit.ulaval.ca/pagespersonnelles/phf/pensee.html>
From akuchlin@mems-exchange.org Sat Mar 10 20:02:35 2001
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Sat, 10 Mar 2001 15:02:35 -0500
Subject: [Catalog-sig] Tasks arising from IPC9
Message-ID: <E14bpZT-00019H-00@ute.cnri.reston.va.us>
Various events related to the Catalog- and Distutils-SIG happened at
IPC9 this past week. To summarize them:
* Sean Reifschneider demonstrated swalow during the Lightning Talks
session and got a favorable reaction from the attendees.
* Packaging was discussed at Paul Prescod's BoF session, and some
decisions were made there. (More about that below...)
* On Developer's Day, Moshe turned over half of his "Batteries Included"
session to me for catalog discussion, and a few more items were
added to the task list.
So, here's the plan of action:
1) For 2.1final, change the Distutils sdist command to construct a
text file containing the metadata for a package. Exactly *what*
metadata to collect was left open for subsequent discussion on the
Catalog-SIG. (Amos has a patch to implement this that I'll look at
when I can.)
This is the only thing to be done in time for 2.1, so it's the only
really pressing task.
2) Once that metadata support is there, someone can start running an
experimental swalow server and begin adding to its database.
If Python 2.2 comes along in 6-12 months, that should be enough
time to have an idea of what should go into 2.2 to support it.
3) Other Distutils changes would be to design and create a package
database, and implement an uninstall command. The 'sdist' command
would also grow an --upload or --register option that would
automatically submit the package to the catalog (but first we'd need
to finalize how that should be done).
I'll make a separate post to start the metadata discussion.
--amk
From akuchlin@mems-exchange.org Sat Mar 10 21:00:40 2001
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Sat, 10 Mar 2001 16:00:40 -0500
Subject: [Catalog-sig] Note about metadata discussion
Message-ID: <E14bqTg-0001B8-00@ute.cnri.reston.va.us>
A discussion of the metadata fields for Python software packages is
now going on in the Distutils SIG. Given that most people are there
and not here, we'll have further discussions there. I'll look into
winding up the Catalog-SIG mailing list this week.
--amk
From biotechinfo2003@yahoo.com Sun Mar 11 16:33:20 2001
From: biotechinfo2003@yahoo.com (biotechinfo2003@yahoo.com)
Date: Sun, 11 Mar 2001 16:33:20
Subject: [Catalog-sig] FREE Biotech Stock Info! 807
Message-ID: <227.320015.846939@juno.com>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Do you want to capitalize on the Biotech Revolution</title>
</head>
<body>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto" align="center"><img border="0" src="http://www.geocities.com/mailtestbox2000/Kiloh_logo.gif" width="204" height="170"></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:Arial">Do
you want to capitalize on the Biotech Revolution? Would you like to add
groundbreaking biotech, pharmaceutical and medical device companies to your
portfolio mix? Does hearing about exciting IPO and private placement offerings
from life sciences companies interest you?</span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:Arial">The
exclusive <b>Ruddy-Carlisle Biotech Infoline</b> service keeps you abreast of
investment opportunities in the life sciences space. Just sign up for it once
and get important information instantly delivered to study at your leisure. Our
service is <b><u>100% FREE</u></b>! <b><span style="color:blue"><a href="mailto:biotechsubscribe@yahoo.com">Sign
up!</a></span></b></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:#003366">Ruddy-Carlisle
Biotech Infoline:</span></i></b></p>
<ul type="disc">
<li class="MsoNormal" style="color:#003366;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial">Instantly
delivers key life sciences investment information directly to you! </span></i></b><o:p>
</o:p>
</li>
<li class="MsoNormal" style="color:#003366;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial">Learn
about biotech, pharmaceutical & medical device investment opportunities
before others! </span></i></b><o:p>
</o:p>
</li>
<li class="MsoNormal" style="color:#003366;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial">Includes
IPO & private placement information! </span></i></b><o:p>
</o:p>
</li>
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:
11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:#003366">100%
FREE!</span></i></b></li>
</ul>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:Arial">For
the entire last decade there were only three profitable biotech companies. At
the end of this year, ten are projected. At the end of 2003, <u>over forty</u>
are projected! The genomic promise is about to be delivered and investors know
it. The <b>Ruddy-Carlisle Biotech Infoline </b>provides you with critical,
decision-making, information that aids the chance of investment success in this
lucrative space. <b><span style="color:blue"><a href="mailto:biotechsubscribe@yahoo.com">Sign
up!</a></span></b></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-family:Arial">Please
Note-</span></b><span style="font-family:Arial"> Your information will only be
shared with companies that are in the life sciences space <u>and</u> pass our
rigorous inspection. Only the best opportunities will come to you.
Ruddy-Carlisle respects your privacy. <b><span style="color:blue"><a href="mailto:biotechsubscribe@yahoo.com">Sign
up!</a></span></b></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p>
<b><span style="font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;
mso-fareast-font-family:"Times New Roman";mso-ansi-language:EN-US;mso-fareast-language:
EN-US;mso-bidi-language:AR-SA">
</p>
</p>List Removal Instructions</span></b><span style="font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;mso-fareast-font-family:
"Times New Roman";mso-ansi-language:EN-US;mso-fareast-language:EN-US;
mso-bidi-language:AR-SA">- Simply click here: <b><span style="color:blue"><a href="mailto:remobiotech@yahoo.com">remove</a></span></b>
to be instantly and permanently removed from our list. Send the blank email to
the address specified. Please do not try to reply to this message.</span>
</body>
</html>
From akuchlin@mems-exchange.org Tue Mar 13 16:08:35 2001
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue, 13 Mar 2001 11:08:35 -0500
Subject: [Catalog-sig] PEP 241 draft
Message-ID: <E14crLf-0003ev-00@ute.cnri.reston.va.us>
[Followups set to distutils-sig@python.org, since that's where most of
the posters are.]
I've checked in a first draft of PEP 241. Here it is; please offer
comments and changes.
PEP: 241
Title: Metadata for Python Software Packages
Version: $Revision: 1.1 $
Author: A.M. Kuchling <amk1@bigfoot.com>
Type: Standards Track
Created: 12-Mar-2001
Status: Draft
Post-History:
Introduction
This PEP specifies the names and semantics of the fields used to store
metadata about Python software packages.
Including Metadata in Packages
The Distutils 'sdist' command will be modified to extract the
metadata fields from the arguments and write them to a file in the
generated zipfile or tarball. This file will be named METADATA
and will be placed in the top directory of the source
distribution (where the README, INSTALL, and other files usually
go).
Authors might expect to include a METADATA file of their own that
would be used instead of the generated file, but this will not be
permitted. It would be confusing if person B makes a custom
release of person A's software, modifies setup.py accordingly, but
uses identical metadata because person B didn't delete the
METADATA file. When running the 'sdist' command, a user-supplied
METADATA file will be ignored and a warning about this action will
be printed.
XXX are we sure RFC-822 is enough?
The METADATA file format is a single set of RFC-822 headers
parseable by the rfc822.py module. The field names listed in the
following section are used as the header names.
Fields
This section specifies the names and semantics of each of the
supported metadata fields.
Name
The name of the package. XXX what's the set of legal characters?
Example: 'BeagleVote'
Version
A string containing the package's version number. This
field should be parseable by one of the Version classes
(StrictVersion or LooseVersion) in the distutils.version
module.
Example: '1.0a2'
Platforms
A (XXX whitespace? comma?)-separated list of platform
specifications. Platform specifications are limited to the
following list:
XXX copy list from PPD? SourceForge?
Example: 'XXX'
Description
A one-line summary of what the package does.
Example: "A module for collecting votes from beagles."
Long-Description (optional)
A longer description of the package that can run to several
paragraphs. (Software that deals with metadata should not
assume any maximum size for this field, though one hopes that
people won't include their instruction manual as the
long-description.)
Example: 'This module collects votes from beagles in order to
determine their electoral wishes. Do NOT try to use this module
with basset hounds; it makes them grumpy.'
Keywords
A list of additional keywords to be used to assist searching
for this package in a larger catalog.
XXX Keywords should probably be constrained to be from a fixed
list, but I don't think this can be enforced by the 'sdist'
command. (The list might be large, and it could only be updated
with new Distutils releases, which seems too inflexible.)
Example: 'dog puppy voting election'
Home-page (optional)
A string containing the URL for the package's home page.
Example: 'http://www.example.com/~cschultz/bvote/'
Author (optional)
A string containing at a minimum the author's name. Contact
information can also be added, separating each line with
newlines.
Example: 'C. Schultz\nUniversal Features Syndicate\nLos Angeles, CA'
Author-email
A string containing the author's e-mail address. It can contain
a name and e-mail address in the legal forms for a RFC-822
'From:' header ("name <email>" or "email (name)"). It's not
optional because cataloging systems can use the e-mail portion
of this field as a unique key representing the author. A
catalog might provide authors the ability to store their GPG
key, personal home page, and other additional metadata *about
the author*. Author-related metadata fields are not covered by
this PEP. (XXX should they be? I think not, since nothing in
this PEP will deal with author data at all.)
Example: 'C. Schultz <cschultz@example.com>'
License
A string selected from a short list of choices, specifying the
license covering the package. Some licenses result in the
software being freely redistributable, so packagers and
resellers can automatically know that they're free to
redistribute the software. Other licenses will require
a careful reading by a human to determine the software can be
repackaged and resold.
The choices are:
XXX copy list from SourceForge, + 'Other'
Copyright
This document has been placed in the public domain.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
From jafo@tummy.com Thu Mar 15 05:45:25 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Wed, 14 Mar 2001 22:45:25 -0700
Subject: [Catalog-sig] Re: [Distutils] PEP 241 draft
In-Reply-To: <E14crLf-0003ev-00@ute.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Tue, Mar 13, 2001 at 11:08:35AM -0500
References: <E14crLf-0003ev-00@ute.cnri.reston.va.us>
Message-ID: <20010314224525.I30951@tummy.com>
On Tue, Mar 13, 2001 at 11:08:35AM -0500, Andrew Kuchling wrote:
> generated zipfile or tarball. This file will be named METADATA
See my previous message for why I don't like "METADATA".
> Authors might expect to include a METADATA file of their own that
> would be used instead of the generated file, but this will not be
> permitted. It would be confusing if person B makes a custom
> release of person A's software, modifies setup.py accordingly, but
> uses identical metadata because person B didn't delete the
> METADATA file. When running the 'sdist' command, a user-supplied
> METADATA file will be ignored and a warning about this action will
> be printed.
Alternate wording:
Developers may not provide their own "METADATA" file. The "sdist"
command will, if it detects an existing "METADATA" file, terminate
with an appropriate error message. This should prevent confusion
caused by the "METADATA" and "setup.py" files being out of sync.
> XXX are we sure RFC-822 is enough?
> The METADATA file format is a single set of RFC-822 headers
> parseable by the rfc822.py module. The field names listed in the
> following section are used as the header names.
RFC822 is an interesting choice. I was initially thinking XML, but I kind
of like the RFC822 idea. Probably good to note above that multi-line
entries must have white-space at the beginning of their continued lines...
>Fields
> Name
>
> The name of the package. XXX what's the set of legal characters?
>
> Example: 'BeagleVote'
Questions: Is it expected this name corresponds either to the name of the
package which is imported, or the package top-level directory name? If so,
what do we do about alternative packages that provide different implementations
of the same functionality? I suppose we could reasonably expect to make
use of "import urllib2 as urllib" to take care of that.
Proposed valid characters: [-a-zA-Z_0-9]
> Platforms
>
> A (XXX whitespace? comma?)-separated list of platform
> specifications. Platform specifications are limited to the
> following list:
Does this include platform name, platform version, and architecture? Like
redhat-7.0-x86, windows-nt-hppa, etc?
> Description
See my other message about "Description" versus "Short-Description" and
"Summary".
What about:
Freely-Redistributable
Group (such as "Database", "Network/SMTP", etc)?
Provides (maybe "urllib2" would provide "urllib"?)
Requires (dependences -- RPM for example has multiple lines of the
form "Requires: initscripts >= 3.25", "Requires: openssl >= 0.9.4")
In general, it looks good.
Sean
--
There is no force so powerful as an idea whose time has come.
-- Everett Dirkson
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From akuchlin@mems-exchange.org Thu Mar 15 17:02:12 2001
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Thu, 15 Mar 2001 12:02:12 -0500
Subject: [Catalog-sig] Re: [Distutils] PEP 241 draft
In-Reply-To: <20010314224525.I30951@tummy.com>; from jafo@tummy.com on Wed, Mar 14, 2001 at 10:45:25PM -0700
References: <E14crLf-0003ev-00@ute.cnri.reston.va.us> <20010314224525.I30951@tummy.com>
Message-ID: <20010315120212.F2440@ute.cnri.reston.va.us>
On Wed, Mar 14, 2001 at 10:45:25PM -0700, Sean Reifschneider wrote:
>Alternate wording:
> Developers may not provide their own "METADATA" file. The "sdist"
More fascist; I like it! Will add it...
>Questions: Is it expected this name corresponds either to the name of the
>package which is imported, or the package top-level directory name? If so,
I don't think so; consider "Sketch", which may not actually
have a Sketch package.
>what do we do about alternative packages that provide different implementations
>of the same functionality? I suppose we could reasonably expect to make
>use of "import urllib2 as urllib" to take care of that.
>Does this include platform name, platform version, and architecture? Like
>redhat-7.0-x86, windows-nt-hppa, etc?
I wish I knew! This is the last remaining XXX in the PEP. Thoughts?
> Freely-Redistributable
> Group (such as "Database", "Network/SMTP", etc)?
> Provides (maybe "urllib2" would provide "urllib"?)
> Requires (dependences -- RPM for example has multiple lines of the
> form "Requires: initscripts >= 3.25", "Requires: openssl >= 0.9.4")
I'm lukewarm; can we decide on syntax for all of those fields?
(Semantics can wait; as long as users can put 'Group: blah', we can
figure out what the groups should be later.) Can
Freely-Redistributable be derived from the License field? (Side
effect: discourages using your own Open Source license). Will
comma-separated values be sufficient for the last 3?
--amk
From phrxy@csv.warwick.ac.uk Thu Mar 15 23:45:22 2001
From: phrxy@csv.warwick.ac.uk (John J. Lee)
Date: Thu, 15 Mar 2001 23:45:22 +0000 (GMT)
Subject: [Catalog-sig] Re: [Distutils] PEP 241 draft
In-Reply-To: <20010315120212.F2440@ute.cnri.reston.va.us>
Message-ID: <Pine.SOL.4.30.0103152343001.26347-100000@mimosa.csv.warwick.ac.uk>
On Thu, 15 Mar 2001, Andrew Kuchling wrote:
[...]
> figure out what the groups should be later.) Can
> Freely-Redistributable be derived from the License field? (Side
> effect: discourages using your own Open Source license). Will
[...]
Freely-Redist. is not something everyone understands in the same way, so I
think it is best done (if at all) as a derived field. That way it is at
least consistent.
John
From jafo@tummy.com Sat Mar 17 08:53:08 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Sat, 17 Mar 2001 01:53:08 -0700
Subject: [Catalog-sig] Re: [Distutils] PEP 241 draft
In-Reply-To: <Pine.SOL.4.30.0103152343001.26347-100000@mimosa.csv.warwick.ac.uk>; from phrxy@csv.warwick.ac.uk on Thu, Mar 15, 2001 at 11:45:22PM +0000
References: <20010315120212.F2440@ute.cnri.reston.va.us> <Pine.SOL.4.30.0103152343001.26347-100000@mimosa.csv.warwick.ac.uk>
Message-ID: <20010317015308.C29139@tummy.com>
On Thu, Mar 15, 2001 at 11:45:22PM +0000, John J. Lee wrote:
>Freely-Redist. is not something everyone understands in the same way, so I
Such is life... There are a lot of things that not everyone understands in
the same way. We put a reasonable definition in the PEP, and that's what's
used as the guide for understanding it. If you think the name is bad,
I'm open to another name, but I think specifying that is useful.
To some, the "Freely-redistributable" field is more important than the
License field. The lack of such a field has constantly been painful in
CPAN. At the least, if we imply this from the License field, the PEP
should list what licenses we imply that from.
On thinking of it more, I'm thinking that another name is probably good.
"Redistributable" with a value of "yes", "no", or "unmodified". For example,
DJB's stuff is freely redistributable ONLY if it's unmodified or binaries
built from an unmodified source.
Sean
--
Linux: When you need to run like a greased weasel.
-- Sean Reifschneider, 1998
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From akuchlin@mems-exchange.org Tue Mar 20 01:17:41 2001
From: akuchlin@mems-exchange.org (A.M. Kuchling)
Date: Mon, 19 Mar 2001 20:17:41 -0500
Subject: [Catalog-sig] PEP 241 posted
Message-ID: <200103200117.UAA00611@mira.erols.com>
I've posted PEP 241 to c.l.py.a, so make any final comments. Time for
me to start implementing...
--amk
From jafo@tummy.com Tue Mar 20 06:49:33 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Mon, 19 Mar 2001 23:49:33 -0700
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
Message-ID: <20010319234933.A4356@tummy.com>
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
PEP-compliant.
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.
Thanks,
Sean
==========================================================================
PEP: 243
Title: Module Repository Upload Mechanism
Version: $Revision$
Author: jafo-pep@tummy.com (Sean Reifschneider)
Status: Draft
Type: Standards Track
Created: 18-Mar-2001
Python-Version: 2.1
Post-History:
Discussions-To: distutils-sig@python.org
Abstract
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
archive/catalog server.
Upload Process
The upload will include the Distutils "PKG-INFO" meta-data
information (as specified in PEP-241 [1]), 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
ENCTYPE="multipart/form-data" encoding.
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' %
ord(byte))").
pkginfo -- The file containing the distribution meta-data (as
specified in PEP-241 [1]).
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
"<os_name>-<os_version>-<platform architecture>".
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.
Return Data
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
processed.
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.
Sample Form
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:
<H1>Upload file</H1>
<FORM NAME="fileupload" METHOD="POST" ACTION="swalowpost.cgi"
ENCTYPE="multipart/form-data">
<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">
</FORM>
Platforms
The following are valid os names:
debian
hpux
mandrake
redhat
solaris
suse
windows
yellowdog
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:
alpha
hppa
ix86
powerpc
sparc
ultrasparc
Status
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 [1] 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
release.
References
[1] Metadata for Python Software Package, Kuchling,
http://python.sourceforge.net/peps/pep-0241.html
Copyright
This document has been placed in the public domain.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
--
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 <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From Paul.Moore@uk.origin-it.com Tue Mar 20 09:25:00 2001
From: Paul.Moore@uk.origin-it.com (Moore, Paul)
Date: Tue, 20 Mar 2001 09:25:00 -0000
Subject: [Catalog-sig] RE: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com>
From: Sean Reifschneider [mailto:jafo@tummy.com]
> PEP: 243
> Title: Module Repository Upload Mechanism
> platform (optional) -- A string representing the target
> platform for this distribution. This is only for binary
> distributions. It is encoded as
> "<os_name>-<os_version>-<platform architecture>".
This probably needs to include the Python version for which a binary
distribution was compiled.
> 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.
Why GPG? Is that available on all platforms? Could PGP signatures be used
for people on Windows (for example), who probably don't have GPG?
> 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:
I'd suggest this format be spelled out. I don't have Linux or Netscape, so I
can't determine what the submitted page should look like from this
description...
> Platforms
>
> The following are valid os names:
>
> debian
> hpux
> mandrake
> redhat
> solaris
> suse
> windows
> yellowdog
dos? beos? mac? This feels very Unix-specific...
> 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).
That's not likely to be precise enough. Is Windows 2000 "2000" or "nt"? It's
binary-compatible with NT. Same goes (and more so) for Windows 9x, which are
most definitely NOT NT, but which are binary-compatible.
Take a Windows security module. It's binary compatible with Windows 9x, NT,
and 2000. But the API calls involved either don't exist, or produce errors
or do nothing on Windows 9x, which has no security features (ducks, waiting
for the "Windows in general has no security features" jokes :-)
Paul.
From jafo@tummy.com Tue Mar 20 10:19:45 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Tue, 20 Mar 2001 03:19:45 -0700
Subject: [Catalog-sig] RE: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com>; from Paul.Moore@uk.origin-it.com on Tue, Mar 20, 2001 at 09:25:00AM -0000
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com>
Message-ID: <20010320031945.Y29553@tummy.com>
On Tue, Mar 20, 2001 at 09:25:00AM -0000, Moore, Paul wrote:
>This probably needs to include the Python version for which a binary
>distribution was compiled.
Good idea.
>Why GPG? Is that available on all platforms? Could PGP signatures be used
Because GPG is available on the server that will be accepting these
connections. My understanding is that GPG can read some PGP encondings
(more now that RSA has fallen out of patent), so I've changed this to
read "GPG-compatible signature".
You will note that it said *OPTIONAL* there...
>I'd suggest this format be spelled out. I don't have Linux or Netscape, so I
>can't determine what the submitted page should look like from this
>description...
I'll see if I can find the RFC which specifies this. It seems like 2388
may be the one, but 1867 seems to look promising also.
>dos? beos? mac? This feels very Unix-specific...
I'd be willing to bet that it covers a larger percentage of non-unix
platforms than it does the unix platforms. I've added the ones listed
above.
>> 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).
>
>That's not likely to be precise enough. Is Windows 2000 "2000" or "nt"? It's
Seems pretty precise to me. Windows 2000 is "2000", NT is "nt", 95 is
"95"... Distutils can't make a judgement about wether a package is likely
to work on other similar platforms. Only somone who knows the system
intimately can really determine if it's likely to break on other similar
platforms. If they are really that close together, then the catalog client
can decide that if it doesn't find a 2k package it should check to see if
there are any NT packages available...
The thing I wondered was wether it was important to differentiate Windows
by the build number, but I think splitting it out by the vendor version is
good enough.
Sean
--
If you talk to God, you are praying; if God talks to you, you have
schizophrenia. -- Thomas Szasz
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From fgranger@altern.org Tue Mar 20 17:58:55 2001
From: fgranger@altern.org (Francois Granger)
Date: Tue, 20 Mar 2001 18:58:55 +0100
Subject: [Catalog-sig] PEP: 243 Title: Module Repository Upload Mechanism
In-Reply-To: <E14fPVR-00029Q-00@mail.python.org>
Message-ID: <B6DD58EF.6E8B%fgranger@altern.org>
on 20/03/01 18:01, catalog-sig-request@python.org at
catalog-sig-request@python.org wrote:
> Platforms
>
> The following are valid os names:
>
> debian
> hpux
> mandrake
> redhat
> solaris
> suse
> windows
> yellowdog
What about MacOS ?
From amos@digicool.com Wed Mar 21 00:13:08 2001
From: amos@digicool.com (Amos Latteier)
Date: Tue, 20 Mar 2001 16:13:08 -0800
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
References: <20010319234933.A4356@tummy.com>
Message-ID: <3AB7F214.9BCF8B30@digicool.com>
Sean Reifschneider wrote:
>
> 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
> PEP-compliant.
First off, I think it may be too early to draft this PEP. It may make
more sense to wait until we have one or more catalog prototypes
available.
I think that most folks agree that eventually the catalog and distutils
should be integrated to allow you to upload your archive as easily as
possible. However, I think that if this is going to be formalized as a
PEP (rather than evolved as we work with catalog servers) then we should
spell out some requirements and use cases.
> The upload will be made to the host "modules.python.org" on port
> 80/tcp.
Was the name of the catalog server decided at the conference? Did we
decide who's in charge of it, etc?
>
> pkginfo -- The file containing the distribution meta-data (as
> specified in PEP-241 [1]).
For source packages this can be extracted from the archive.
> platform (optional) -- A string representing the target
> platform for this distribution. This is only for binary
> distributions. It is encoded as
> "<os_name>-<os_version>-<platform architecture>".
Why not just use the platform meta-data? I see no need for two different
and incompatible ways to specify platform information.
> 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.
It might also be used by human downloaders.
> Status
>
> 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 [1] 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
> release.
I'd like to talk to you about the catalog server. I have built several
prototypes myself, and I'd love to talk with you more about the project.
-Amos
--
Amos Latteier mailto:amos@digicool.com
Digital Creations http://www.digicool.com
From jafo@tummy.com Wed Mar 21 00:46:37 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Tue, 20 Mar 2001 17:46:37 -0700
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <3AB7F214.9BCF8B30@digicool.com>; from amos@digicool.com on Tue, Mar 20, 2001 at 04:13:08PM -0800
References: <20010319234933.A4356@tummy.com> <3AB7F214.9BCF8B30@digicool.com>
Message-ID: <20010320174637.F1466@tummy.com>
On Tue, Mar 20, 2001 at 04:13:08PM -0800, Amos Latteier wrote:
>First off, I think it may be too early to draft this PEP. It may make
>more sense to wait until we have one or more catalog prototypes
>available.
Well, I *DID* demo my prototype catalog server at Python 9... The problem
I face is that it's not really very useful until we actually have stuff
*IN* it.
I also see the upload facility is really orthogonal to the issues of the
actual catalog. You don't need a catalog server to implement the upload,
and therefore I don't see any real reason for delaying this for the catalog
server. Having an upload facility in the 2.1 distutils will allow us to
get some real-world data for the catalog server.
>PEP (rather than evolved as we work with catalog servers) then we should
>spell out some requirements and use cases.
How is that different from what has been going on with the discussions
around my swalow project over about the last month? It's been on the
distutils, catalog, and python mailing lists...
>Was the name of the catalog server decided at the conference? Did we
>decide who's in charge of it, etc?
The name "modules.python.org" was suggested by AMK, I believe. At the
current time, it probably makes sense to set it up on one of my boxes, and
I'll take responsibility for it...
>For source packages this can be extracted from the archive.
Yeah, and I actually have the code written to do this for .tar.* files. I
wasn't sure I wanted to require that the upload server implement that
though -- I'll take this as a vote that it should.
>> platform (optional) -- A string representing the target
>> platform for this distribution. This is only for binary
>> distributions. It is encoded as
>> "<os_name>-<os_version>-<platform architecture>".
>
>Why not just use the platform meta-data? I see no need for two different
>and incompatible ways to specify platform information.
Sorry, what platform meta-data are you speaking of?
>I'd like to talk to you about the catalog server. I have built several
>prototypes myself, and I'd love to talk with you more about the project.
I thought that's what you were doing. At the moment I have a working
prototype of a catalog server using the working name "swalow", which is
available from the ftp.tummy.com FTP site. The package upload code I also
have prototyped, but haven't yet released it.
Sean
--
"I'll thrash you like a Netscape process on a machine with 640K."
-- John Shipman, 1998
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From amos@digicool.com Wed Mar 21 01:03:40 2001
From: amos@digicool.com (Amos Latteier)
Date: Tue, 20 Mar 2001 17:03:40 -0800
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
References: <20010319234933.A4356@tummy.com> <3AB7F214.9BCF8B30@digicool.com> <20010320174637.F1466@tummy.com>
Message-ID: <3AB7FDEC.B9B13FE3@digicool.com>
Sean Reifschneider wrote:
>
> Well, I *DID* demo my prototype catalog server at Python 9...
I wish I had been able to be there :-(
> I also see the upload facility is really orthogonal to the issues of the
> actual catalog. You don't need a catalog server to implement the upload,
> and therefore I don't see any real reason for delaying this for the catalog
> server.
True. But see below for some caveats.
> >Was the name of the catalog server decided at the conference? Did we
> >decide who's in charge of it, etc?
>
> The name "modules.python.org" was suggested by AMK, I believe. At the
> current time, it probably makes sense to set it up on one of my boxes, and
> I'll take responsibility for it...
Great!
> Yeah, and I actually have the code written to do this for .tar.* files. I
> wasn't sure I wanted to require that the upload server implement that
> though
This is an example of how the implemention of the catalog server may
have a bearing on how we want the distutils integration to work. I can
think of some other details that might make a difference, for example,
does the catalog sever prefer FTP or HTTP communication?
> >Why not just use the platform meta-data? I see no need for two different
> >and incompatible ways to specify platform information.
>
> Sorry, what platform meta-data are you speaking of?
Um, the one in PKG_INFO (PEP 241). Maybe you have something else in
mind.
> I thought that's what you were doing. At the moment I have a working
> prototype of a catalog server using the working name "swalow", which is
> available from the ftp.tummy.com FTP site.
Cool, I'll check it out. Right now I'm working on a catalog server in
Zope. I have lots of different ideas, so I'd love to see what you've
done. I'll try to make my prototype available in a couple days.
-Amos
--
Amos Latteier mailto:amos@digicool.com
Digital Creations http://www.digicool.com
From akuchlin@mems-exchange.org Wed Mar 21 01:55:57 2001
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue, 20 Mar 2001 20:55:57 -0500
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <3AB7F214.9BCF8B30@digicool.com>; from amos@digicool.com on Tue, Mar 20, 2001 at 04:13:08PM -0800
References: <20010319234933.A4356@tummy.com> <3AB7F214.9BCF8B30@digicool.com>
Message-ID: <20010320205557.A21466@newcnri.cnri.reston.va.us>
On Tue, Mar 20, 2001 at 04:13:08PM -0800, Amos Latteier wrote:
>> platform (optional) -- A string representing the target
>> platform for this distribution. This is only for binary
>> distributions. It is encoded as
>> "<os_name>-<os_version>-<platform architecture>".
>
>Why not just use the platform meta-data? I see no need for two different
>and incompatible ways to specify platform information.
The developer, at least according to PEP 241 as it currently stands,
can only provide high-level platform info, not low-level details like
OS versions or CPU, and they may not need to do so at all.
I do want to get BDFL go-ahead before checking in any PEP 243 changes,
though, and if Guido says no, that would settle it. PEP 241 is a
must-have for 2.1, IMHO, and he assented to it at IPC9, but 243 is
more of a "wouldn't it be nice if...", and if that's considered too
risky for 2.1b2, that's fine with me.
--amk
From mal@lemburg.com Wed Mar 21 10:36:46 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 21 Mar 2001 11:36:46 +0100
Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com>
Message-ID: <3AB8843E.C32FEE74@lemburg.com>
"Moore, Paul" wrote:
>
> From: Sean Reifschneider [mailto:jafo@tummy.com]
> > PEP: 243
> > Title: Module Repository Upload Mechanism
> > platform (optional) -- A string representing the target
> > platform for this distribution. This is only for binary
> > distributions. It is encoded as
> > "<os_name>-<os_version>-<platform architecture>".
>
> This probably needs to include the Python version for which a binary
> distribution was compiled.
...at least for Windows this is mandatory. You get nasty error
messages otherwise.
> > 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.
>
> Why GPG? Is that available on all platforms? Could PGP signatures be used
> for people on Windows (for example), who probably don't have GPG?
I'd say go with PGP -- it is far more available and known than
GPG... after all the intent of a signature is for the people
who download the code to check it and if they don't know what
GPG is, then it is of no practical use for them (hard to tell,
if it's of practical use for them at all ;-).
> > 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:
>
> I'd suggest this format be spelled out. I don't have Linux or Netscape, so I
> can't determine what the submitted page should look like from this
> description...
Can't we just specify: use HTTP POST with multipart/form-data encoding
and then redirect to the RFC (can't remember the number) or Netscape
description of the form upload proposal ?!
> > Platforms
> >
> > The following are valid os names:
> >
> > debian
> > hpux
> > mandrake
> > redhat
> > solaris
> > suse
> > windows
> > yellowdog
>
> dos? beos? mac? This feels very Unix-specific...
>
> > 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).
>
> That's not likely to be precise enough. Is Windows 2000 "2000" or "nt"? It's
> binary-compatible with NT. Same goes (and more so) for Windows 9x, which are
> most definitely NOT NT, but which are binary-compatible.
>
> Take a Windows security module. It's binary compatible with Windows 9x, NT,
> and 2000. But the API calls involved either don't exist, or produce errors
> or do nothing on Windows 9x, which has no security features (ducks, waiting
> for the "Windows in general has no security features" jokes :-)
You may want to take a look at platform.py available from my
Python Pages for ways to "define" a platform information string.
--
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting: http://www.egenix.com/
Python Pages: http://www.lemburg.com/python/
From moshez@zadka.site.co.il Wed Mar 21 11:42:58 2001
From: moshez@zadka.site.co.il (Moshe Zadka)
Date: Wed, 21 Mar 2001 13:42:58 +0200
Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <3AB8843E.C32FEE74@lemburg.com>
References: <3AB8843E.C32FEE74@lemburg.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com>
Message-ID: <E14fh10-0002bl-00@darjeeling>
On Wed, 21 Mar 2001 11:36:46 +0100, "M.-A. Lemburg" <mal@lemburg.com> wrote:
> I'd say go with PGP -- it is far more available and known than
> GPG
As a data point, newer PGPs can read signatures made by GPG, and GPG
can read any signature made by PGP. However, many people do not have
PGP in their operating systems. There is the OpenPGP standard which both
newer PGPs and GPG conform to --- while Sean seems to have a problem
referring to standards instead of to implementations (<0.9 wink>), he
should learn to cope with it. It is RFC 2440, and I suggest simply
putting a refernce to the RFC in the PEP
> Can't we just specify: use HTTP POST with multipart/form-data encoding
> and then redirect to the RFC (can't remember the number)
RFC 2388
+1
(Someone should really patch up pep2html.py to make RFC mentions hyperlinks)
(The code can probably be stolen from pydoc.py)
--
"I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
-- Wichert Akkerman (on debian-private)| easier, more seductive.
For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
From moshez@zadka.site.co.il Wed Mar 21 13:03:18 2001
From: moshez@zadka.site.co.il (Moshe Zadka)
Date: Wed, 21 Mar 2001 15:03:18 +0200
Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <E14fh10-0002bl-00@darjeeling>
References: <E14fh10-0002bl-00@darjeeling>, <3AB8843E.C32FEE74@lemburg.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com>
Message-ID: <E14fiGk-0002kr-00@darjeeling>
On Wed, 21 Mar 2001 13:42:58 +0200, Moshe Zadka <moshez@zadka.site.co.il> wrote:
> (Someone should really patch up pep2html.py to make RFC mentions hyperlinks)
Someone just did.
--
"I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
-- Wichert Akkerman (on debian-private)| easier, more seductive.
For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
From phrxy@csv.warwick.ac.uk Wed Mar 21 20:00:43 2001
From: phrxy@csv.warwick.ac.uk (John J. Lee)
Date: Wed, 21 Mar 2001 20:00:43 +0000 (GMT)
Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository
Upload Mechanism
In-Reply-To: <3AB8843E.C32FEE74@lemburg.com>
Message-ID: <Pine.SOL.4.30.0103211955040.9955-100000@mimosa.csv.warwick.ac.uk>
On Wed, 21 Mar 2001, M.-A. Lemburg wrote:
> "Moore, Paul" wrote:
[...]
> > Why GPG? Is that available on all platforms? Could PGP signatures be used
> > for people on Windows (for example), who probably don't have GPG?
>
> I'd say go with PGP -- it is far more available and known than
> GPG... after all the intent of a signature is for the people
[...]
As has been pointed out already, the idea was for signatures to be gpg
*readable*. I think this includes all pgp signatures. There is an IDEA
module if that's important for signatures (can't remember), and of course
RSA, which is now free.
John
From jafo@tummy.com Fri Mar 23 00:09:47 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Thu, 22 Mar 2001 17:09:47 -0700
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <3AB7FDEC.B9B13FE3@digicool.com>; from amos@digicool.com on Tue, Mar 20, 2001 at 05:03:40PM -0800
References: <20010319234933.A4356@tummy.com> <3AB7F214.9BCF8B30@digicool.com> <20010320174637.F1466@tummy.com> <3AB7FDEC.B9B13FE3@digicool.com>
Message-ID: <20010322170947.X1466@tummy.com>
On Tue, Mar 20, 2001 at 05:03:40PM -0800, Amos Latteier wrote:
>This is an example of how the implemention of the catalog server may
>have a bearing on how we want the distutils integration to work. I can
>think of some other details that might make a difference, for example,
>does the catalog sever prefer FTP or HTTP communication?
Currently, I am using HTTP exclusively for communication with the catalog
server, but I expect that FTP or HTTP will be usable for downloading the
actual files. Doing catalog searches and other of those sorts of lookups
I've been doing via HTTP...
>> >Why not just use the platform meta-data? I see no need for two different
>> >and incompatible ways to specify platform information.
>>
>> Sorry, what platform meta-data are you speaking of?
>
>Um, the one in PKG_INFO (PEP 241). Maybe you have something else in
>mind.
Ahh, that's a new field since the copy of 241 I reviewed. The problem is
that PEP241 doesn't specify the actual contents of that field, so I guess
what I'll do is specify it in 243? Does that make sense?
>Cool, I'll check it out. Right now I'm working on a catalog server in
>Zope. I have lots of different ideas, so I'd love to see what you've
>done. I'll try to make my prototype available in a couple days.
Excellent.
Sean
--
Home is where your source is. -- Sean Reifschneider, 1999
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From jafo@tummy.com Fri Mar 23 00:13:44 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Thu, 22 Mar 2001 17:13:44 -0700
Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <E14fh10-0002bl-00@darjeeling>; from moshez@zadka.site.co.il on Wed, Mar 21, 2001 at 01:42:58PM +0200
References: <3AB8843E.C32FEE74@lemburg.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <E14fh10-0002bl-00@darjeeling>
Message-ID: <20010322171344.Y1466@tummy.com>
On Wed, Mar 21, 2001 at 01:42:58PM +0200, Moshe Zadka wrote:
>newer PGPs and GPG conform to --- while Sean seems to have a problem
>referring to standards instead of to implementations (<0.9 wink>), he
I love the saying: "If you don't have time to do it right, when will you
ever find time to do it over?" However, I'm guilty as charged. ;-)
Sean
--
Her eyes were like two brown circles with big black dots in the center.
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From jafo@tummy.com Sat Mar 24 08:51:42 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Sat, 24 Mar 2001 01:51:42 -0700
Subject: [Catalog-sig] PEP: 243 Title: Module Repository Upload Mechanism
In-Reply-To: <B6DD58EF.6E8B%fgranger@altern.org>; from fgranger@altern.org on Tue, Mar 20, 2001 at 06:58:55PM +0100
References: <E14fPVR-00029Q-00@mail.python.org> <B6DD58EF.6E8B%fgranger@altern.org>
Message-ID: <20010324015142.M4804@tummy.com>
On Tue, Mar 20, 2001 at 06:58:55PM +0100, Francois Granger wrote:
>What about MacOS ?
Done.
Sean
--
His thoughts tumbled in his head, making and breaking alliances like
underpants in a dryer without Cling Free.
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From jafo@tummy.com Sat Mar 24 09:01:49 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Sat, 24 Mar 2001 02:01:49 -0700
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <20010320205557.A21466@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Tue, Mar 20, 2001 at 08:55:57PM -0500
References: <20010319234933.A4356@tummy.com> <3AB7F214.9BCF8B30@digicool.com> <20010320205557.A21466@newcnri.cnri.reston.va.us>
Message-ID: <20010324020149.N4804@tummy.com>
On Tue, Mar 20, 2001 at 08:55:57PM -0500, Andrew Kuchling wrote:
>The developer, at least according to PEP 241 as it currently stands,
>can only provide high-level platform info, not low-level details like
Indeed. That's why it's listed as being for binary distributions only.
It'll have to be pulled either from the system or the user at the time of
binary build. This issue doesn't have to be resolved right now though
because most of what I want to see uploaded initially is source
distributions. Once we have the experience of cataloging and distributing
the source distributions, we'll be in a better position to handle the
binary issues.
>I do want to get BDFL go-ahead before checking in any PEP 243 changes,
>though, and if Guido says no, that would settle it. PEP 241 is a
>must-have for 2.1, IMHO, and he assented to it at IPC9, but 243 is
>more of a "wouldn't it be nice if...", and if that's considered too
>risky for 2.1b2, that's fine with me.
I'm firmly convinced that the upload tool is a necessary part of getting
the data we require for the cataloging. If we can't get it in to 2.1, I'll
make it standalone. While reduce the accessability of it to the
developers, it will hopefully give it the maturity it needs to get into
Distutils for 2.2.
So, we define "sdist --submit", but not "bdist --submit" at the moment,
defer the platform issue until 2.2, and in the mean time we hopefully get
a serious start to the cataloging server.
Sean
--
Millions long for immortality who don't know what to do with themselves
on a rainy Sunday afternoon. -- Heinlein
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From jafo@tummy.com Sat Mar 24 09:13:21 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Sat, 24 Mar 2001 02:13:21 -0700
Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <3AB8843E.C32FEE74@lemburg.com>; from mal@lemburg.com on Wed, Mar 21, 2001 at 11:36:46AM +0100
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com>
Message-ID: <20010324021321.O4804@tummy.com>
On Wed, Mar 21, 2001 at 11:36:46AM +0100, M.-A. Lemburg wrote:
>...at least for Windows this is mandatory. You get nasty error
>messages otherwise.
It's gonna be required on most platforms for at least some of the
distributions.
>I'd say go with PGP -- it is far more available and known than
>GPG... after all the intent of a signature is for the people
>who download the code to check it and if they don't know what
>GPG is, then it is of no practical use for them (hard to tell,
>if it's of practical use for them at all ;-).
I'm thinking of specifying OpenPGP as the standard and leave the
implementation outta it.
>Can't we just specify: use HTTP POST with multipart/form-data encoding
>and then redirect to the RFC (can't remember the number) or Netscape
>description of the form upload proposal ?!
RFC 2388 is what I'll change it to.
>You may want to take a look at platform.py available from my
>Python Pages for ways to "define" a platform information string.
Most excellent. I don't think we want it to include kernel information
though...
Sean
--
Got Source?
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From moshez@zadka.site.co.il Sat Mar 24 09:45:37 2001
From: moshez@zadka.site.co.il (Moshe Zadka)
Date: Sat, 24 Mar 2001 11:45:37 +0200
Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <20010324021321.O4804@tummy.com>
References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com>
Message-ID: <E14gkc5-0005c4-00@darjeeling>
On Sat, 24 Mar 2001 02:13:21 -0700, Sean Reifschneider <jafo@tummy.com> wrote:
> Most excellent. I don't think we want it to include kernel information
> though...
I'm not sure if you can get away from it completely.
Three words for you:
Large file support
--
"I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
-- Wichert Akkerman (on debian-private)| easier, more seductive.
For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
From jafo@tummy.com Sat Mar 24 10:42:13 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Sat, 24 Mar 2001 03:42:13 -0700
Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <E14gkc5-0005c4-00@darjeeling>; from moshez@zadka.site.co.il on Sat, Mar 24, 2001 at 11:45:37AM +0200
References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <20010324021321.O4804@tummy.com> <E14gkc5-0005c4-00@darjeeling>
Message-ID: <20010324034212.I1466@tummy.com>
On Sat, Mar 24, 2001 at 11:45:37AM +0200, Moshe Zadka wrote:
>I'm not sure if you can get away from it completely.
>Three words for you: Large file support
Yeah, but knowing if you're running 2.2.18 doesn't tell you the information
you want to know -- do I have the LFS patch in my kernel.
You make my head hurt. ;-)
Sean
--
"Bill and Ted on cryptography: If you are really us... What number are we
thinking of?" -- Sean Reifschneider, 1998
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From martin@loewis.home.cs.tu-berlin.de Sat Mar 24 12:54:04 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 24 Mar 2001 13:54:04 +0100
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <E14gkc5-0005c4-00@darjeeling> (message from Moshe Zadka on Sat,
24 Mar 2001 11:45:37 +0200)
References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <E14gkc5-0005c4-00@darjeeling>
Message-ID: <200103241254.f2OCs4400787@mira.informatik.hu-berlin.de>
> > Most excellent. I don't think we want it to include kernel information
> > though...
>
> I'm not sure if you can get away from it completely.
>
> Three words for you:
> Large file support
Maybe I'm missing something, but ... I don't think the packaging
system should deal with "minor" details of the operating
system. Instead, the package should, at run-time, determine whether
the feature is present or not. Otherwise, we end up with packages that
require, say, /proc support (*), and fail to install if /proc was not
mounted, or is missing from the kernel configuration. IMO, the right
behaviour in this case is to produce an exception at run-time (whether
from a deliberate test, or by just using the missing feature).
Regards,
Martin
(*) Or the Fiber API, for you Windows users :-)
From mal@lemburg.com Sat Mar 24 13:38:57 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 24 Mar 2001 14:38:57 +0100
Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload
Mechanism
References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <20010324021321.O4804@tummy.com> <E14gkc5-0005c4-00@darjeeling> <20010324034212.I1466@tummy.com>
Message-ID: <3ABCA371.A8F73C4F@lemburg.com>
Sean Reifschneider wrote:
>
> On Sat, Mar 24, 2001 at 11:45:37AM +0200, Moshe Zadka wrote:
> >I'm not sure if you can get away from it completely.
> >Three words for you: Large file support
>
> Yeah, but knowing if you're running 2.2.18 doesn't tell you the information
> you want to know -- do I have the LFS patch in my kernel.
>
> You make my head hurt. ;-)
With the pointer to platform.py I just wanted to let you know
that there is a Python module for these sort of things out there
which can handle many different platform issues. Whether you use
the different features or not is really totally up to you...
BTW, I think that information such as the libc version are more
important than, say, the patch level of the OS. Again, these
issues are OS-specific (e.g. on Windows the C RTL version isn't
all that important since MS tries hard to maintain backward
compatibility).
--
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting: http://www.egenix.com/
Python Pages: http://www.lemburg.com/python/
From jafo@tummy.com Sat Mar 24 20:02:14 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Sat, 24 Mar 2001 13:02:14 -0700
Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <3ABCA371.A8F73C4F@lemburg.com>; from mal@lemburg.com on Sat, Mar 24, 2001 at 02:38:57PM +0100
References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <20010324021321.O4804@tummy.com> <E14gkc5-0005c4-00@darjeeling> <20010324034212.I1466@tummy.com> <3ABCA371.A8F73C4F@lemburg.com>
Message-ID: <20010324130214.J1466@tummy.com>
On Sat, Mar 24, 2001 at 02:38:57PM +0100, M.-A. Lemburg wrote:
>With the pointer to platform.py I just wanted to let you know
>that there is a Python module for these sort of things out there
It doesn't detect LFS though, does it? I don't see that it does...
It's definitely useful though.
>BTW, I think that information such as the libc version are more
>important than, say, the patch level of the OS. Again, these
OS patch level tends to indicate the set of libraries you have. Much
easier than having to list *ALL* the libraries on your system which might
impact a binary module. RPM actually looks at the files to see what
they're linked against, which would be the ultimate...
Sean
--
Language is the most important .. uh.. I think you know what I'm trying
to say. -- Steve Martin
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From jafo@tummy.com Sat Mar 24 23:17:35 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Sat, 24 Mar 2001 16:17:35 -0700
Subject: [Catalog-sig] RFC: PEP243: Module Repository Upload Mechanism
Message-ID: <20010324161735.A19818@tummy.com>
Included below is the version of PEP243 after it's initial round of review.
I welcome any feedback.
Thanks,
Sean
============================================================================
PEP: 243
Title: Module Repository Upload Mechanism
Version: $Revision$
Author: jafo-pep@tummy.com (Sean Reifschneider)
Status: Draft
Type: Standards Track
Created: 18-Mar-2001
Python-Version: 2.1
Post-History:
Discussions-To: distutils-sig@python.org
Abstract
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
archive/catalog server.
Upload Process
The upload will include the Distutils "PKG-INFO" meta-data
information (as specified in PEP-241 [1]), 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
ENCTYPE="multipart/form-data" encoding [RFC1867].
The upload will be made to the host "modules.python.org" on port
80/tcp (POST http://modules.python.org:80/swalowpost.cgi). 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' %
ord(byte))").
pkginfo (optional) -- The file containing the distribution
meta-data (as specified in PEP-241 [1]). Note that if this is not
included, the distribution file is expected to be in .tar format
(gzipped and bzipped compreesed are allowed) or .zip format, with a
"PKG-INFO" file in the top-level directory it extracts
("package-1.00/PKG-INFO").
infomd5sum (required if pkginfo field is present) -- 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
"<os_name>-<os_version>-<platform architecture>-<python
version>".
signature (optional) -- A OpenPGP-compatible signature [RFC2440]
of the uploaded distribution as signed by the author. This may be
used by the cataloging system to automate acceptance of uploads.
protocol_version -- A string indicating the protocol version that
the client supports. This document describes protocol version "1".
Return Data
The status of the upload will be reported using HTTP non-standard
("X-*)" headers. The "X-Swalow-Status" header may have the following
values:
SUCCESS -- Indicates that the upload has succeeded.
FAILURE -- The upload is, for some reason, unable to be
processed.
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...
Optionally, there may be a "X-Swalow-Reason" header which includes a
human-readable string which provides more detailed information about
the "X-Swalow-Status".
If there is no "X-Swalow-Status" header, or it does not contain one of
the three strings above, it should be treated as a temporary failure.
Example:
>>> f = urllib.urlopen('http://modules.python.org:80/swalowpost.cgi')
>>> s = f.headers['x-swalow-status']
>>> s = s + ': ' + f.headers.get('x-swalow-reason', '<None>')
>>> print s
FAILURE: Required field "distribution" missing.
Sample Form
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:
<H1>Upload file</H1>
<FORM NAME="fileupload" METHOD="POST" ACTION="swalowpost.cgi"
ENCTYPE="multipart/form-data">
<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="hidden" NAME="protocol_version" VALUE="1"><BR>
<INPUT TYPE="SUBMIT" VALUE="Upload">
</FORM>
Platforms
The following are valid os names:
aix beos debian dos freebsd hpux mac macos mandrake netbsd
openbsd qnx redhat solaris suse windows yellowdog
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, "2000" and "nt" (Windows),
"9.04" (HP-UX), "7.0" (RedHat, Mandrake).
The following are valid architectures:
alpha hppa ix86 powerpc sparc ultrasparc
Status
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 [1] 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
release.
References
[1] Metadata for Python Software Package, Kuchling,
http://python.sourceforge.net/peps/pep-0241.html
[RFC1867] Form-based File Upload in HTML
http://www.faqs.org/rfcs/rfc1867.html
[RFC2440] OpenPGP Message Format
http://www.faqs.org/rfcs/rfc2440.html
Copyright
This document has been placed in the public domain.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
--
A smart terminal is not a smart*ass* terminal, but rather a terminal
you can educate. -- Rob Pike
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From amos@digicool.com Sun Mar 25 02:25:44 2001
From: amos@digicool.com (Amos Latteier)
Date: Sat, 24 Mar 2001 18:25:44 -0800
Subject: [Catalog-sig] [ANN] Prototype catalog server available
Message-ID: <3ABD5728.D84001F3@digicool.com>
Hi,
I got inspired after looking at Sean's catalog server stuff, and have
coded up a catalog server in Zope.
http://63.230.174.230:8080/archive
You can upload source and binary packages and search and browse. The
catalog expects PKG-INFO files in source distributions.
To upload a package click 'join' and create an account. Then you can
upload new source packages, and add binary packages to existing source
packages.
I've uploaded distutils 1.0.2pre as an example. I've also uploaded the
catalog server itself as a package.
Please try it out. Create an account and upload your packages. Let me
know if you run into any problems.
There are tons of improvements that could be done. Top of my list are
working out an API for use by command line tools and refining and
implementing the distutils upload protocol. Also, there are a lot of
security improvements that could be done.
Let me know what you think.
-Amos
--
Amos Latteier mailto:amos@digicool.com
Digital Creations http://www.digicool.com
From martin@loewis.home.cs.tu-berlin.de Sun Mar 25 09:10:57 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 25 Mar 2001 11:10:57 +0200
Subject: [Catalog-sig] [ANN] Prototype catalog server available
In-Reply-To: <3ABD5728.D84001F3@digicool.com> (message from Amos Latteier on
Sat, 24 Mar 2001 18:25:44 -0800)
References: <3ABD5728.D84001F3@digicool.com>
Message-ID: <200103250910.f2P9Ava06003@mira.informatik.hu-berlin.de>
> I got inspired after looking at Sean's catalog server stuff, and have
> coded up a catalog server in Zope.
>
> http://63.230.174.230:8080/archive
>
> You can upload source and binary packages and search and browse. The
> catalog expects PKG-INFO files in source distributions.
I'm getting the impression that this server does not conform to the
protocol proposed in PEP 243. I've tried uploading a file using
<html>
<body>
<H1>Upload file</H1>
<FORM NAME="fileupload" METHOD="POST" ACTION="http://63.230.174.230:8080/archive/addArchiveForm"
ENCTYPE="multipart/form-data">
<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="hidden" NAME="protocol_version" VALUE="1"><BR>
<INPUT TYPE="SUBMIT" VALUE="Upload">
</FORM>
</body>
</html>
That is, I started Lynx, loaded this file, filled in the distribution
field, and initiated upload. In turn, I got a page with a 500 status
code, and the document
Zope Error
Zope has encountered an error while publishing this resource.
Error Type: AttributeError
Error Value: absolute_url
Traceback (innermost last):
File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 223, in publish_
module
File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 187, in publish
File /home/amos/Trunk/lib/python/Zope/__init__.py, line 221, in zpublisher_ex
ception_hook
(Object: RoleManager)
File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 162, in publish
File /home/amos/Trunk/lib/python/ZPublisher/BaseRequest.py, line 462, in trav
erse
File /home/amos/Trunk/lib/python/Products/CMFCore/CookieCrumbler.py, line 229 (Object: ElementWithAttributes)
File /home/amos/Trunk/lib/python/Products/CMFCore/CookieCrumbler.py, line 260
, in getLoginURL
(Object: ElementWithAttributes)
AttributeError: (see above)
Of course, my Lynx client did *not* submit any kind of cookie; sending
a cookie is not mandated in PEP 243.
Regards,
Martin
From martin@loewis.home.cs.tu-berlin.de Sun Mar 25 10:25:26 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 25 Mar 2001 12:25:26 +0200
Subject: [Catalog-sig] RFC: PEP243: Module Repository Upload Mechanism
In-Reply-To: <20010324161735.A19818@tummy.com> (message from Sean
Reifschneider on Sat, 24 Mar 2001 16:17:35 -0700)
References: <20010324161735.A19818@tummy.com>
Message-ID: <200103251025.f2PAPQO06464@mira.informatik.hu-berlin.de>
Hi Sean,
I have a few minor comments to your draft.
> This form is posted using ENCTYPE="multipart/form-data" encoding [RFC1867].
This RFC is informative only; the RFC specifying the
multipart/form-data content type is RFC 2388.
> signature (optional) -- A OpenPGP-compatible signature [RFC2440]
> of the uploaded distribution as signed by the author. This may be
> used by the cataloging system to automate acceptance of uploads.
Is that required to be an ASCII armor (6.2), or can it be a raw
detached signature (10.3)? If the latter, your form should probably
not expect text input there (even if it is an armor, a multiline input
would be more appropriate).
Is it also acceptable to send a Signed Message (10.2) as the
distribution? If so, is it then still mandatory to send the md5sum?
Does the md5sum then apply to the signed or the unsigned distribution?
> 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:
Wasn't there some complaint about that wording already? What kind of
requirement does that state, beyond what is already specified above
(host, port, method, mime-type, field list).
E.g. I believe Netscape will send all fields, even if left empty. Is
that a requirement, or is it allowed to leave out fields which are
described as optional? Also, that could be read into mandating a
specific order in which the fields must be sent? Is that a
requirement?
My proposal is to not use the word "must" in that entire section, and
to make it clear otherwise that the section is informative.
> I currently have a proof-of-concept client and server implemented.
Is that available somewhere?
Regards,
Martin
From jafo@tummy.com Sun Mar 25 10:45:36 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Sun, 25 Mar 2001 03:45:36 -0700
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <200103241254.f2OCs4400787@mira.informatik.hu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Sat, Mar 24, 2001 at 01:54:04PM +0100
References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <E14gkc5-0005c4-00@darjeeling> <200103241254.f2OCs4400787@mira.informatik.hu-berlin.de>
Message-ID: <20010325034536.B24546@tummy.com>
On Sat, Mar 24, 2001 at 01:54:04PM +0100, Martin v. Loewis wrote:
>mounted, or is missing from the kernel configuration. IMO, the right
>behaviour in this case is to produce an exception at run-time (whether
Sure, but how do you do that for C extension modules which use OS features
you don't have (like LFS)?
Sean
--
Her eyes were like two brown circles with big black dots in the center.
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From mal@lemburg.com Sun Mar 25 14:15:58 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sun, 25 Mar 2001 16:15:58 +0200
Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload
Mechanism
References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <20010324021321.O4804@tummy.com> <E14gkc5-0005c4-00@darjeeling> <20010324034212.I1466@tummy.com> <3ABCA371.A8F73C4F@lemburg.com> <20010324130214.J1466@tummy.com>
Message-ID: <3ABDFD9E.B7B2E68B@lemburg.com>
Sean Reifschneider wrote:
>
> On Sat, Mar 24, 2001 at 02:38:57PM +0100, M.-A. Lemburg wrote:
> >With the pointer to platform.py I just wanted to let you know
> >that there is a Python module for these sort of things out there
>
> It doesn't detect LFS though, does it? I don't see that it does...
> It's definitely useful though.
The module is intended to include checks like these if they are
important for applications, so if you can provide an API which
checks for LFS, then I'd be happy to include it in platform.py.
> >BTW, I think that information such as the libc version are more
> >important than, say, the patch level of the OS. Again, these
>
> OS patch level tends to indicate the set of libraries you have. Much
> easier than having to list *ALL* the libraries on your system which might
> impact a binary module. RPM actually looks at the files to see what
> they're linked against, which would be the ultimate...
distutils has all the technology to check for these. I'd suggest
to have the package download tools use these to verify their
existance. Of course, this can only be done *after* downloading
the package, but hey, can't have everything ;-)
--
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting: http://www.egenix.com/
Python Pages: http://www.lemburg.com/python/
From m_konermann@gmx.de Sun Mar 25 15:06:34 2001
From: m_konermann@gmx.de (Marcus Konermann)
Date: Sun, 25 Mar 2001 17:06:34 +0200
Subject: [Catalog-sig] Need help on =?iso-8859-1?Q?python=B4s?= glob module
Message-ID: <3ABE0979.1F32203A@gmx.de>
Hallo !
i´m programming a project in my graduation with python an need help on
python´s glob module. I don´t know the search routine, in which python
searches through different files.
For example: I let python search through the actuall directory with the
command *.out (which specifies all files ending of ".out"). There are
three files in the actuall directory named: ist.out, soll.out and
rc.out.
First, python takes the "rc.out" file, then the "ist.out" file and at
last the "soll.out" file. So, it seems not to be an alphabetical order,
in which python searches through this files.
Please, can you tell me the search routine for python´s glob module ?
Thanks a lot
Grettings
Marcus Konermann
From guido@digicool.com Sun Mar 25 16:58:00 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 25 Mar 2001 11:58:00 -0500
Subject: [Catalog-sig] Need help on =?iso-8859-1?Q?python=B4s?= glob module
In-Reply-To: Your message of "Sun, 25 Mar 2001 17:06:34 +0200."
<3ABE0979.1F32203A@gmx.de>
References: <3ABE0979.1F32203A@gmx.de>
Message-ID: <200103251658.LAA04284@cj20424-a.reston1.va.home.com>
> Hallo !
Hi Marcus!
You've posted this question to the wrong list. For questions like
this, please write to help@python.org -- or post to comp.lang.python.
> i´m programming a project in my graduation with python an need help on
> python´s glob module. I don´t know the search routine, in which python
> searches through different files.
> For example: I let python search through the actuall directory with the
> command *.out (which specifies all files ending of ".out"). There are
> three files in the actuall directory named: ist.out, soll.out and
> rc.out.
> First, python takes the "rc.out" file, then the "ist.out" file and at
> last the "soll.out" file. So, it seems not to be an alphabetical order,
> in which python searches through this files.
> Please, can you tell me the search routine for python´s glob module ?
>
> Thanks a lot
> Grettings
> Marcus Konermann
The source code for glob is in the file glob.py in the standard
library. The matching is actually done in fnmatch.py, but that
shouldn't matter. The search order you're seeing is because the files
aren't listed in alphabetical order in the directory (even though you
always get your directory listing from ls in alphabetical order -- ls
sorts the list itself).
It's easy to sort the list yourself, using the sort() method on lists:
>>> L = glob.glob("*.py")
>>> L
['rc.out', 'ist.out', 'soll.out']
>>> L.sort()
>>> L
['ist.out', 'rc.out', 'soll.out']
>>>
--Guido van Rossum (home page: http://www.python.org/~guido/)
From martin@loewis.home.cs.tu-berlin.de Sun Mar 25 17:40:00 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 25 Mar 2001 19:40:00 +0200
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <20010325034536.B24546@tummy.com> (message from Sean
Reifschneider on Sun, 25 Mar 2001 03:45:36 -0700)
References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <E14gkc5-0005c4-00@darjeeling> <200103241254.f2OCs4400787@mira.informatik.hu-berlin.de> <20010325034536.B24546@tummy.com>
Message-ID: <200103251740.f2PHe0k00831@mira.informatik.hu-berlin.de>
> On Sat, Mar 24, 2001 at 01:54:04PM +0100, Martin v. Loewis wrote:
> >mounted, or is missing from the kernel configuration. IMO, the right
> >behaviour in this case is to produce an exception at run-time (whether
>
> Sure, but how do you do that for C extension modules which use OS features
> you don't have (like LFS)?
I'm not sure I understand the question. The Python core enables or
disables large file API usage at configuration time, by calling
ftell64 instead of ftell, or using long objects to represent inode
numbers instead of integers. That is of no concern for extension
modules.
Even if an extension module would use the transitional large file API
(i.e. the *64 functions), that is foremost a concern of the C library,
not the operating system kernel. E.g. on Linux, ftell64 is always
available (atleast since glibc 2, and perhaps longer), no matter
whether the kernel supports it or not. If the C extension module might
expect a feature not to work properly (e.g. the Unicode API on Win98),
it can perform run-time checks and fall-back, or just raise an
exception if the C library function fails.
Regards,
Martin
From amos@digicool.com Sun Mar 25 18:58:07 2001
From: amos@digicool.com (Amos Latteier)
Date: Sun, 25 Mar 2001 13:58:07 -0500
Subject: [Catalog-sig] [ANN] Prototype catalog server available
In-Reply-To: <200103250910.f2P9Ava06003@mira.informatik.hu-berlin.de>
Message-ID: <web-1718055@digicool.com>
On Sun, 25 Mar 2001 11:10:57 +0200
"Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
wrote:
> I'm getting the impression that this server does not
> conform to the
> protocol proposed in PEP 243.
Right you are. I should have been more explicit in my email
about this. This is something that I plan to add soon.
Thanks for trying it out.
-Amos
From jafo@tummy.com Sun Mar 25 22:46:36 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Sun, 25 Mar 2001 15:46:36 -0700
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <200103251740.f2PHe0k00831@mira.informatik.hu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Sun, Mar 25, 2001 at 07:40:00PM +0200
References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <E14gkc5-0005c4-00@darjeeling> <200103241254.f2OCs4400787@mira.informatik.hu-berlin.de> <20010325034536.B24546@tummy.com> <200103251740.f2PHe0k00831@mira.informatik.hu-berlin.de>
Message-ID: <20010325154636.Y1466@tummy.com>
On Sun, Mar 25, 2001 at 07:40:00PM +0200, Martin v. Loewis wrote:
>I'm not sure I understand the question. The Python core enables or
>disables large file API usage at configuration time, by calling
>ftell64 instead of ftell, or using long objects to represent inode
You almost make it sound like autoconf is obsolete... The point I took
Moshe to be making was that in a conditional-compilation world, there's
some data that simply looking at the OS name and rev isn't going to pick
up.
Sean
--
Today's robots are very primitive, capable of understanding only a few simple
instructions such as 'go left', 'go right', and 'build car'. -- John Sladek
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From jafo@tummy.com Mon Mar 26 08:35:58 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Mon, 26 Mar 2001 01:35:58 -0700
Subject: [Catalog-sig] ANNOUNCE: Distutils upload patch (PEP243)
Message-ID: <20010326013558.A9281@tummy.com>
I've got the server and client side of my PEP243 implementation (for
uploading distributions made by distutils to the repository server) built.
I've also created the code for distutils (2.1b2) to do the upload. For
example:
guin:python-netstring$ ./setup.py sdist --submit
[...]
gzip -f9 dist/python-netstring-1.14.tar
removing 'python-netstring-1.14' (and everything under it)
Submitting to repository server...
sending dist/python-netstring-1.14.tar.gz...
Succeeded.
done.
Currently, I have the repository server set up on our "public service"
server "community.tummy.com".
The files you will need are:
ftp://ftp.tummy.com/pub/tummy/swalow/swalow-1.13/distutils-swalow.patch
ftp://ftp.tummy.com/pub/tummy/swalow/swalow-1.13/swalowsupp.py
See the README below for information on how to apply it.
The server for handling the requests is also available at the above site,
you'll need a few support modules as well (like the tar module for
extraction of the PKG-INFO file).
I need to update the repository server and client for PEP241, but that
should be pretty straight-forward. Also, if anyone else wants to get
copies of the data sent to my repository, I can certainly arrange that...
Any comments?
Sean
=========================
swalow + Distutils README
Sean Reifschneider <jafo-swalow@tummy.com>
==========================================
The file "distutils-swalow.patch" contains a patch against the 2.1b2
distutils which allows "setup.py sdist --submit" to upload the completed
distribution file to the repository server. This will allow automatic or
semi-automatic submissions of modules.
To gain this functionality, apply the above patch, and copy "swalowsupp.py"
into the main distutils package directory.
If the environment variable "PYTHON_MODULE_SERVER" is set, that value
overrides the default host for uploading the distribution to.
--
That weapon will replace your tongue. You will learn to speak through
it. And your poetry will now be written with blood. -- _Dead_Man_
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From martin@loewis.home.cs.tu-berlin.de Mon Mar 26 06:21:43 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon, 26 Mar 2001 08:21:43 +0200
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <20010325154636.Y1466@tummy.com> (message from Sean Reifschneider
on Sun, 25 Mar 2001 15:46:36 -0700)
References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <E14gkc5-0005c4-00@darjeeling> <200103241254.f2OCs4400787@mira.informatik.hu-berlin.de> <20010325034536.B24546@tummy.com> <200103251740.f2PHe0k00831@mira.informatik.hu-berlin.de> <20010325154636.Y1466@tummy.com>
Message-ID: <200103260621.f2Q6LhA00879@mira.informatik.hu-berlin.de>
> On Sun, Mar 25, 2001 at 07:40:00PM +0200, Martin v. Loewis wrote:
> >I'm not sure I understand the question. The Python core enables or
> >disables large file API usage at configuration time, by calling
> >ftell64 instead of ftell, or using long objects to represent inode
>
> You almost make it sound like autoconf is obsolete... The point I took
> Moshe to be making was that in a conditional-compilation world, there's
> some data that simply looking at the OS name and rev isn't going to pick
> up.
Maybe I lost track: I thought we are talking about binary
packages. When you have a binary package, it is already tailored for a
specific system, so there is no need to detect capabilities at
installation time.
autoconf is for configuring source packages, in particular for systems
that you've never heard of - and which might still be supported (in
source form) thanks to feature tests. In a world of dying Unix
variants (and the remaing Unix variants following standards more
closely), it is becoming more and more obsolete, yes.
Regards,
Martin
From jafo@tummy.com Mon Mar 26 08:49:40 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Mon, 26 Mar 2001 01:49:40 -0700
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <200103260621.f2Q6LhA00879@mira.informatik.hu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Mon, Mar 26, 2001 at 08:21:43AM +0200
References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <E14gkc5-0005c4-00@darjeeling> <200103241254.f2OCs4400787@mira.informatik.hu-berlin.de> <20010325034536.B24546@tummy.com> <200103251740.f2PHe0k00831@mira.informatik.hu-berlin.de> <20010325154636.Y1466@tummy.com> <200103260621.f2Q6LhA00879@mira.informatik.hu-berlin.de>
Message-ID: <20010326014940.Z1466@tummy.com>
On Mon, Mar 26, 2001 at 08:21:43AM +0200, Martin v. Loewis wrote:
>packages. When you have a binary package, it is already tailored for a
>specific system, so there is no need to detect capabilities at
>installation time.
Sure there is... If you have half a dozen binary packages, how do you
determine the one that was built against the set of capabilities that your
system supports?
Sean
--
Why isn't phonetic spelled the way it sounds?
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From martin@loewis.home.cs.tu-berlin.de Mon Mar 26 09:23:29 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon, 26 Mar 2001 11:23:29 +0200
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <20010326014940.Z1466@tummy.com> (message from Sean Reifschneider
on Mon, 26 Mar 2001 01:49:40 -0700)
References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <E14gkc5-0005c4-00@darjeeling> <200103241254.f2OCs4400787@mira.informatik.hu-berlin.de> <20010325034536.B24546@tummy.com> <200103251740.f2PHe0k00831@mira.informatik.hu-berlin.de> <20010325154636.Y1466@tummy.com> <200103260621.f2Q6LhA00879@mira.informatik.hu-berlin.de> <20010326014940.Z1466@tummy.com>
Message-ID: <200103260923.f2Q9NTZ01681@mira.informatik.hu-berlin.de>
> On Mon, Mar 26, 2001 at 08:21:43AM +0200, Martin v. Loewis wrote:
> >packages. When you have a binary package, it is already tailored for a
> >specific system, so there is no need to detect capabilities at
> >installation time.
>
> Sure there is... If you have half a dozen binary packages, how do you
> determine the one that was built against the set of capabilities that your
> system supports?
If it's half a dozen, you take the one that matches your operating
system name and version; for Linux, you probably use the distribution
name, if it offers that much choice.
I think it is unrealistic that people will build binary Python
packages with and without LFS support, or produce other variants based
on capabilities that can be detected at compilation time. I find that
it is extremely time-consuming to produce two binary packages (Redhat
and W2k); I doubt that we'll have 6 binary packages available for many
packages.
Does CPAN even have the notion of binary packages?
Regards,
Martin
From jafo@tummy.com Mon Mar 26 09:46:05 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Mon, 26 Mar 2001 02:46:05 -0700
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <200103260923.f2Q9NTZ01681@mira.informatik.hu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Mon, Mar 26, 2001 at 11:23:29AM +0200
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <E14gkc5-0005c4-00@darjeeling> <200103241254.f2OCs4400787@mira.informatik.hu-berlin.de> <20010325034536.B24546@tummy.com> <200103251740.f2PHe0k00831@mira.informatik.hu-berlin.de> <20010325154636.Y1466@tummy.com> <200103260621.f2Q6LhA00879@mira.informatik.hu-berlin.de> <20010326014940.Z1466@tummy.com> <200103260923.f2Q9NTZ01681@mira.informatik.hu-berlin.de>
Message-ID: <20010326024605.D1466@tummy.com>
On Mon, Mar 26, 2001 at 11:23:29AM +0200, Martin v. Loewis wrote:
>I think it is unrealistic that people will build binary Python
>packages with and without LFS support, or produce other variants based
Don't think "one person building two packages", think "two people each
building the package on their system and then wanting to share it". It
becomes real problematic if you are running an "almost stock" version of a
distribution... I ran a 5.2 box with the latest GTK and the older glibc
for a long time -- I know something about this. ;-)
Sean
--
Tools may limit the user, but the utility of tools is limited by the
skill of the user. -- Leonard Compagno
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From akuchlin@mems-exchange.org Mon Mar 26 15:31:36 2001
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Mon, 26 Mar 2001 10:31:36 -0500
Subject: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism
In-Reply-To: <200103260923.f2Q9NTZ01681@mira.informatik.hu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Mon, Mar 26, 2001 at 11:23:29AM +0200
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <E14gkc5-0005c4-00@darjeeling> <200103241254.f2OCs4400787@mira.informatik.hu-berlin.de> <20010325034536.B24546@tummy.com> <200103251740.f2PHe0k00831@mira.informatik.hu-berlin.de> <20010325154636.Y1466@tummy.com> <200103260621.f2Q6LhA00879@mira.informatik.hu-berlin.de> <20010326014940.Z1466@tummy.com> <200103260923.f2Q9NTZ01681@mira.informatik.hu-berlin.de>
Message-ID: <20010326103136.D20540@ute.cnri.reston.va.us>
On Mon, Mar 26, 2001 at 11:23:29AM +0200, Martin v. Loewis wrote:
>Does CPAN even have the notion of binary packages?
I don't believe it does, except perhaps for Perl itself.
--amk
From amos@digicool.com Wed Mar 28 02:31:18 2001
From: amos@digicool.com (Amos Latteier)
Date: Tue, 27 Mar 2001 18:31:18 -0800
Subject: [Catalog-sig] [ANN] Prototype catalog server updated
Message-ID: <3AC14CF6.93BF6029@digicool.com>
Hello Pythonistas,
I've updated my prototype catalog server
http://63.230.174.230:8080/archive
It now keeps track of who uploaded what. Plus, the registration process
sends email, so you need to provide a valid email address. Also, you can
now edit your user account information. It still does not implement pep
243.
To contribute packages, get the lastest distutils (1.0.2pre) which
implements PEP 241. Create a package. Create a user account on the
catalog server, and upload your your package.
If you just want to play around, you can manually create a PKG-INFO file
for your archive and upload that.
I'd love feedback. Does this seem like I'm going in the right direction?
What could be done to make it easier for uploaders and/or downloaders.
Did you encounter any errors? Does the server not parse your package
correctly?
Enjoy!
-Amos
P.S. The source of the catalog server is available on the catalog
server. (Though, I cheated, and added a PKG-INFO file manually.)
--
Amos Latteier mailto:amos@digicool.com
Digital Creations http://www.digicool.com
From thomas.heller@ion-tof.com Wed Mar 28 06:34:53 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed, 28 Mar 2001 08:34:53 +0200
Subject: [Catalog-sig] Re: [Distutils] [ANN] Prototype catalog server updated
References: <3AC14CF6.93BF6029@digicool.com>
Message-ID: <002d01c0b751$331b3930$e000a8c0@thomasnotebook>
Amos,
the upload failes for me, this is what I get from IE5.5.
Thomas
Zope Error
Zope has encountered an error while publishing this resource.
Error Type: ParseError
Error Value: ('Unknown archive format', 'application/x-zip-compressed', None)
Troubleshooting Suggestions
The URL may be incorrect.
The parameters passed to this resource may be incorrect.
A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to the HTML source for this page.
If the error persists please contact the site maintainer. Thank you for your patience.
Traceback (innermost last):
File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 223, in publish_module
File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 187, in publish
File /home/amos/Trunk/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook
(Object: RoleManager)
File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 171, in publish
File /home/amos/Trunk/lib/python/ZPublisher/mapply.py, line 160, in mapply
(Object: addArchive)
File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 112, in call_object
(Object: addArchive)
File /home/amos/Trunk/lib/python/Products/NetDist/ArchiveManager.py, line 409, in addArchive
(Object: RoleManager)
File /home/amos/Trunk/lib/python/Products/NetDist/Archive.py, line 69, in update
(Object: RoleManager)
File /home/amos/Trunk/lib/python/Products/NetDist/Parse.py, line 56, in parse_meta_data
ParseError: (see above)
From martin@loewis.home.cs.tu-berlin.de Wed Mar 28 07:40:28 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 28 Mar 2001 09:40:28 +0200
Subject: [Catalog-sig] [ANN] Prototype catalog server updated
In-Reply-To: <3AC14CF6.93BF6029@digicool.com> (message from Amos Latteier on
Tue, 27 Mar 2001 18:31:18 -0800)
References: <3AC14CF6.93BF6029@digicool.com>
Message-ID: <200103280740.f2S7eSU01092@mira.informatik.hu-berlin.de>
> I'd love feedback. Does this seem like I'm going in the right direction?
Unfortunately, it does not look that way to me. I was hoping that
support for the PEP 243 protocol has priority - so I'd rather expect
to tell the system my PGP public key, instead of telling it my home
page.
Having a second implementation of the PEP is important, so that we can
find out whether it is well-enough specified to allow to survive for
the next year or so.
Regards,
Martin
From amos@digicool.com Thu Mar 29 18:18:05 2001
From: amos@digicool.com (Amos Latteier)
Date: Thu, 29 Mar 2001 10:18:05 -0800
Subject: [Catalog-sig] Re: [Distutils] [ANN] Prototype catalog server updated
References: <3AC14CF6.93BF6029@digicool.com> <002d01c0b751$331b3930$e000a8c0@thomasnotebook>
Message-ID: <3AC37C5D.A2B546EA@digicool.com>
Thomas Heller wrote:
> the upload failes for me, this is what I get from IE5.5.
>
> Zope Error
> Zope has encountered an error while publishing this resource.
> Error Type: ParseError
> Error Value: ('Unknown archive format', 'application/x-zip-compressed', None)
This should be fixed now.
Thanks for the bug report!
-Amos
--
Amos Latteier mailto:amos@digicool.com
Digital Creations http://www.digicool.com
From amos@digicool.com Thu Mar 29 18:23:54 2001
From: amos@digicool.com (Amos Latteier)
Date: Thu, 29 Mar 2001 10:23:54 -0800
Subject: [Catalog-sig] [ANN] Prototype catalog server updated
References: <3AC14CF6.93BF6029@digicool.com> <200103280740.f2S7eSU01092@mira.informatik.hu-berlin.de>
Message-ID: <3AC37DBA.2CE2D5AD@digicool.com>
"Martin v. Loewis" wrote:
>
> > I'd love feedback. Does this seem like I'm going in the right direction?
>
> Unfortunately, it does not look that way to me. I was hoping that
> support for the PEP 243 protocol has priority - so I'd rather expect
> to tell the system my PGP public key, instead of telling it my home
> page.
Supporting PEP 243 is a priority of mine. As is allowing authors to
upload their public keys, and OpenPGP signature files when they upload
packages. I just haven't gotten there yet. So hopefully I'm heading in
the right direction, but too slowly for you to perceive it ;-)
> Having a second implementation of the PEP is important, so that we can
> find out whether it is well-enough specified to allow to survive for
> the next year or so.
I agree.
-Amos
--
Amos Latteier mailto:amos@digicool.com
Digital Creations http://www.digicool.com
From thomas.heller@ion-tof.com Thu Mar 29 18:56:31 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Thu, 29 Mar 2001 20:56:31 +0200
Subject: [Catalog-sig] Re: [Distutils] [ANN] Prototype catalog server updated
References: <3AC14CF6.93BF6029@digicool.com> <002d01c0b751$331b3930$e000a8c0@thomasnotebook> <3AC37C5D.A2B546EA@digicool.com>
Message-ID: <053b01c0b881$f8196640$e000a8c0@thomasnotebook>
> > the upload failes for me, this is what I get from IE5.5.
> >
> > Zope Error
> > Zope has encountered an error while publishing this resource.
> > Error Type: ParseError
> > Error Value: ('Unknown archive format', 'application/x-zip-compressed', None)
>
> This should be fixed now.
Still it doesn't work, now I get (my package HAS a PKG-INFO file, see
listing at the bottom):
Zope Error
Zope has encountered an error while publishing this resource.
Error Type: ParseError
Error Value: Archive does not contain a PKG-INFO file
Troubleshooting Suggestions
The URL may be incorrect.
The parameters passed to this resource may be incorrect.
A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to the HTML source for this page.
If the error persists please contact the site maintainer. Thank you for your patience.
Traceback (innermost last):
File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 223, in publish_module
File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 187, in publish
File /home/amos/Trunk/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook
(Object: RoleManager)
File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 171, in publish
File /home/amos/Trunk/lib/python/ZPublisher/mapply.py, line 160, in mapply
(Object: addArchive)
File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 112, in call_object
(Object: addArchive)
File /home/amos/Trunk/lib/python/Products/NetDist/ArchiveManager.py, line 409, in addArchive
(Object: RoleManager)
File /home/amos/Trunk/lib/python/Products/NetDist/Archive.py, line 69, in update
(Object: RoleManager)
File /home/amos/Trunk/lib/python/Products/NetDist/Parse.py, line 66, in parse_meta_data
ParseError: (see above)
------------
Here is the contents of the file I tried to upload:
C:\sf\py2exe\dist>unzip -l py2exe-0.2.4pre.zip
Archive: py2exe-0.2.4pre.zip
Length Date Time Name
-------- ---- ---- ----
0 03-29-01 20:51 py2exe-0.2.4pre/
0 03-29-01 20:51 py2exe-0.2.4pre/docs/
15041 03-23-01 12:01 py2exe-0.2.4pre/docs/index.html
782 03-02-01 22:48 py2exe-0.2.4pre/docs/py2exe.css
4197 02-17-01 23:00 py2exe-0.2.4pre/docs/py2exe.jpg
1087 02-28-01 09:40 py2exe-0.2.4pre/LICENSE.txt
604 03-29-01 20:50 py2exe-0.2.4pre/MANIFEST
243 03-07-01 14:16 py2exe-0.2.4pre/MANIFEST.in
410 03-29-01 20:51 py2exe-0.2.4pre/PKG-INFO
0 03-29-01 20:51 py2exe-0.2.4pre/py2exe/
31880 03-08-01 21:46 py2exe-0.2.4pre/py2exe/py2exe-0.2.4.py
32781 03-26-01 21:34 py2exe-0.2.4pre/py2exe/py2exe.py
7411 03-21-01 17:13 py2exe-0.2.4pre/py2exe/support.py
1353 03-21-01 17:12 py2exe-0.2.4pre/py2exe/__init__.py
407 02-02-01 20:06 py2exe-0.2.4pre/README.txt
12913 03-29-01 20:49 py2exe-0.2.4pre/setup.py
0 03-29-01 20:51 py2exe-0.2.4pre/source/
2249 03-21-01 17:10 py2exe-0.2.4pre/source/archive.h
1710 03-23-01 11:03 py2exe-0.2.4pre/source/icon.rc
766 02-08-01 10:32 py2exe-0.2.4pre/source/icon1.ico
2199 03-26-01 09:28 py2exe-0.2.4pre/source/py.c
11305 03-21-01 17:10 py2exe-0.2.4pre/source/py2exe_util.c
282 03-20-01 22:18 py2exe-0.2.4pre/source/python_run.c
453 03-20-01 22:22 py2exe-0.2.4pre/source/resource.h
2827 03-26-01 21:02 py2exe-0.2.4pre/source/run.c
1975 03-21-01 17:11 py2exe-0.2.4pre/source/run_w.c
11925 03-23-01 11:04 py2exe-0.2.4pre/source/start.c
0 03-29-01 20:51 py2exe-0.2.4pre/source/zlib/
0 03-29-01 20:51 py2exe-0.2.4pre/source/zlib/static32/
113416 08-18-00 21:33 py2exe-0.2.4pre/source/zlib/static32/zlibstat.lib
8140 01-16-01 16:12 py2exe-0.2.4pre/source/zlib/zconf.h
41791 01-16-01 16:12 py2exe-0.2.4pre/source/zlib/zlib.h
0 03-29-01 20:51 py2exe-0.2.4pre/tools1.5/
25237 02-19-01 20:44 py2exe-0.2.4pre/tools1.5/imputil.py
14685 02-19-01 20:44 py2exe-0.2.4pre/tools1.5/modulefinder.py
0 02-19-01 20:44 py2exe-0.2.4pre/tools1.5/__init__.py
0 03-29-01 20:51 py2exe-0.2.4pre/tools2.0/
15106 02-15-01 23:16 py2exe-0.2.4pre/tools2.0/modulefinder.py
0 01-16-01 16:12 py2exe-0.2.4pre/tools2.0/__init__.py
0 03-29-01 20:51 py2exe-0.2.4pre/tools2.1/
14702 11-06-00 04:49 py2exe-0.2.4pre/tools2.1/modulefinder.py
0 01-16-01 16:12 py2exe-0.2.4pre/tools2.1/__init__.py
-------- -------
377877 42 files
C:\sf\py2exe\dist>
Thomas