[Catalog-sig] Withdrawing PEP 262

[Aaron Sterling]

10/14/2002 5:21:00 PM, Chris Liechti <cliechti@gmx.net> wrote:

>no no...reason: firewalls. 

>sure that'd be cool, but that should be only allowed with signed packages and 
otherwise only
>with a BIG warning box...


Oh...Yeah...  Man the real world is a drag. Especially the security aspect of it. 

That being said, let me list some rough specifications for such a system(the sane one) 
and see if anyone agrees with any of them.


1) As Chris pointed out, the catalog should be divided into two levels, signed and 
unsigned.

2) The catalog(I propose calling it the Python Package Catalog, or PPC, at least for 
the purpose of this discussion) should be structured thusly. Three rfc822 fields: DATE, 
PPC-Signed, PPC-Unsigned. This divides the catalog into two subcatalogs. Each entry in 
a sub-catalog occupies one and only one line. This line takes the form <package name> 
<SPACE> <package infofile URL> <SPACE> <package website> <SPACE> <package summary>. The 
package name is the name of the package, the package infofile URL is the URL of the 
package infofile(described in 4), the package website is the packages' website. The 
package summary is an eighty charachter summary of the package. This is for use in the 
browser.

3) Access to the primary PPC at python.org should be kept to a minimum to conserve 
bandwidth. This can be facilitated by keeping a local copy of the PPC on each machine. 
This carries with the extra benefit of redundency. When it is time to download a 
package, the Local PPC(LPPC) is consulted. If the DATE field in the LPPC is expired a 
fresh copy is downloaded from python.org.

4) This is a hack I think. It would be preferable to simply have one universal format 
for all packages on all platforms, that not being the case, we need some means of 
redirecting general requests for a package into a concrete URL for that specific 
platform. This can be accomplished with infofiles. Infofiles would be plaintext, either 
ASCII or LATIN-1. They would essentially be a catalog of the different distributions of 
the package for different platforms. Each platform for which that package is supported 
would have one and only one line given to it. This line would take the form <platform> 
<SPACE> <platform specific URL>. The platform is simply sys.platform so that the code 
is guaranteed to know what it is. The plaform specific URL is the url of the package 
for that specific platform.

5) In addition to the LPPC, there should be the IPPC (Installed PPC), this is almost 
the same format as the PPC, but contains only the subset of the PPC that is installed 
on the local system. The change in format is the substitution of a reference to the 
packages' local package database entry for the infofile reference.

6) The stucture of the local package database would be essentially the same as under 
PEP 262

There is obviously a lot of stuff that needs to be fleshed out, such as where do these 
files live and the UI for the Package Browser, to give just two examples. As a whole 
though, how does it hold up? 

Aaron