RE: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism
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 "
- -<platform architecture>".
This probably needs to include the Python version for which a binary distribution was compiled.
signature (optional) -- A GPG signature of the uploaded distribution as signed by the author. This may be used by the cataloging system to automate acceptance of uploads.
Why GPG? Is that available on all platforms? Could PGP signatures be used for people on Windows (for example), who probably don't have GPG?
The upload client must submit the page in the same form as Netscape Navigator version 4.76 for Linux produces when presented with the following form:
I'd suggest this format be spelled out. I don't have Linux or Netscape, so I can't determine what the submitted page should look like from this description...
Platforms
The following are valid os names:
debian hpux mandrake redhat solaris suse windows yellowdog
dos? beos? mac? This feels very Unix-specific...
Version is the official version string specified by the vendor for the particular release. For example, "nt" (Windows), "9.04" (HP-UX), "7.0" (RedHat, Mandrake).
That's not likely to be precise enough. Is Windows 2000 "2000" or "nt"? It's binary-compatible with NT. Same goes (and more so) for Windows 9x, which are most definitely NOT NT, but which are binary-compatible. Take a Windows security module. It's binary compatible with Windows 9x, NT, and 2000. But the API calls involved either don't exist, or produce errors or do nothing on Windows 9x, which has no security features (ducks, waiting for the "Windows in general has no security features" jokes :-) Paul.
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
Sean Reifschneider wrote:
...
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.
There are more: "aix", "qnx".
...
Kind regards Rene Liebscher
"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 "
- -<platform architecture>". This probably needs to include the Python version for which a binary distribution was compiled.
...at least for Windows this is mandatory. You get nasty error messages otherwise.
signature (optional) -- A GPG signature of the uploaded distribution as signed by the author. This may be used by the cataloging system to automate acceptance of uploads.
Why GPG? Is that available on all platforms? Could PGP signatures be used for people on Windows (for example), who probably don't have GPG?
I'd say go with PGP -- it is far more available and known than GPG... after all the intent of a signature is for the people who download the code to check it and if they don't know what GPG is, then it is of no practical use for them (hard to tell, if it's of practical use for them at all ;-).
The upload client must submit the page in the same form as Netscape Navigator version 4.76 for Linux produces when presented with the following form:
I'd suggest this format be spelled out. I don't have Linux or Netscape, so I can't determine what the submitted page should look like from this description...
Can't we just specify: use HTTP POST with multipart/form-data encoding and then redirect to the RFC (can't remember the number) or Netscape description of the form upload proposal ?!
Platforms
The following are valid os names:
debian hpux mandrake redhat solaris suse windows yellowdog
dos? beos? mac? This feels very Unix-specific...
Version is the official version string specified by the vendor for the particular release. For example, "nt" (Windows), "9.04" (HP-UX), "7.0" (RedHat, Mandrake).
That's not likely to be precise enough. Is Windows 2000 "2000" or "nt"? It's binary-compatible with NT. Same goes (and more so) for Windows 9x, which are most definitely NOT NT, but which are binary-compatible.
Take a Windows security module. It's binary compatible with Windows 9x, NT, and 2000. But the API calls involved either don't exist, or produce errors or do nothing on Windows 9x, which has no security features (ducks, waiting for the "Windows in general has no security features" jokes :-)
You may want to take a look at platform.py available from my Python Pages for ways to "define" a platform information string. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
On Wed, 21 Mar 2001 11:36:46 +0100, "M.-A. Lemburg"
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
On Wed, 21 Mar 2001 13:42:58 +0200, Moshe Zadka
(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
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
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
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
On Sat, 24 Mar 2001 02:13:21 -0700, Sean Reifschneider
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
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
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/
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
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/
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 :-)
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
participants (7)
-
John J. Lee -
M.-A. Lemburg -
Martin v. Loewis -
Moore, Paul -
Moshe Zadka -
Rene Liebscher -
Sean Reifschneider