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: 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 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: 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: 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> Do you want to capitalize on the Biotech Revolution

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?

The exclusive Ruddy-Carlisle Biotech Infoline 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 100% FREE! Sign up!

Ruddy-Carlisle Biotech Infoline:

Instantly delivers key life sciences investment information directly to you!
Learn about biotech, pharmaceutical & medical device investment opportunities before others!
Includes IPO & private placement information!
100% FREE!

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, over forty are projected! The genomic promise is about to be delivered and investors know it. The Ruddy-Carlisle Biotech Infoline provides you with critical, decision-making, information that aids the chance of investment success in this lucrative space. Sign up!

Please Note- Your information will only be shared with companies that are in the life sciences space and pass our rigorous inspection. Only the best opportunities will come to you. Ruddy-Carlisle respects your privacy. Sign up!

List Removal Instructions- Simply click here: remove 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. 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: [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 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 " 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 ' 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: ; from akuchlin@mems-exchange.org on Tue, Mar 13, 2001 at 11:08:35AM -0500 References: 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 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: <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: 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: ; from phrxy@csv.warwick.ac.uk on Thu, Mar 15, 2001 at 11:45:22PM +0000 References: <20010315120212.F2440@ute.cnri.reston.va.us> 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 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 "--". 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:

Upload file

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 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 > "--". 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 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: Message-ID: 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 > "--". 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 >> "--". > >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 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 >> "--". > >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 > > "--". > > 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: On Wed, 21 Mar 2001 11:36:46 +0100, "M.-A. Lemburg" 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: References: , <3AB8843E.C32FEE74@lemburg.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> Message-ID: On Wed, 21 Mar 2001 13:42:58 +0200, Moshe Zadka 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: 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 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: ; 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> 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 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: ; from fgranger@altern.org on Tue, Mar 20, 2001 at 06:58:55PM +0100 References: 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 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 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 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: On Sat, 24 Mar 2001 02:13:21 -0700, Sean Reifschneider 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: ; 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> 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 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: (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> 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> <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> <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 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 "---". 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', '') >>> 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:

Upload file

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 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

Upload file

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> <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 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> <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> <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: On Sun, 25 Mar 2001 11:10:57 +0200 "Martin v. Loewis" 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> <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 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 ========================================== 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 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> <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> <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 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> <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> <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 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> <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