[Catalog-sig] Withdrawing PEP 262

[Lucio Torre]

Aaron,

i a bit lost in time, i hope this is still relevant. comments below.

Aaron Sterling wrote:

>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.
>  
>
I can testify for the imposrtance of this issue!.. On the other hand, 
simplicity should also be considered a plus.

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

Im sure i lost something, but where are dependencies? What about when 
you want to install this you should have that installed first?
Thats a great feature.

Also, being a debian fan, i recommend allowing each instalation to 
configure it sources. Python.org could provide a basic one, parnassus 
another. something like that.

i dont find cerificates too important. i dont really know the authors of 
the code i download, and i dont think python.org should tell anyone 
about the security/autenticity of my code.

>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.
>
I like the 'apt-get update' way better. Why force update? New versions 
and incompatibilities always arise that should be considered.

>
>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.
>  
>
Here we also have issues with python versions. What if im still using 
python 2.7 and python 3000 is out? I should be able to select the 
packages that are compatible with python 2.7

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

The way i see it is like this: (sorry for the extra noise in this touchy 
issue)

$INSTALLDB/Packages - A Database of Installed Python Packages (PEP 262)
$INSTALLDB/Config/Sources.py - A sources list. Something like this:

sources = {
    "python.org":{
        "url":"http://python.org/",
        "desc":"Default source",
    }
    "parnasuss": {
            etc...
    }
}

As you can see, im implying the use of python source as the format of 
the configuration files. I think its better because:
a- its more felixible
b- we already have a parser
c- everyone knows how to read it
d- security issues with "pakcage info files" can be solved easily

$INSTALLDB/Cache/$SOURCE.package.list

List of packages. This file should be very similar to the sources.py 
file, and include the requiered information of a packe. I

$INSTALLDB/Keys/*

Public keys of people you trust.

And usage should go like this:

dsitutils update
    check every source for updates. perform a head on every url, 
download new versions.

distutils install package [-s SOURCE]
    look for the package in cache. if its found in more than one source, 
complain and stop. require usage of 'source'
    check prerequisites. in they are not met, say so and stop.
    download. (http)
    check for signatures.
    install.

etc.

I think that we should keep these goals in mind:
1- No automation/intelligence until we are sure it can be done right. I 
dont want automatic dependency matching and endeless loops like dselect.
2- it should not force us to keep an up to date installation of python, 
but help us in doing so.
3- it should be easily wrapped. So i can use debian to keep my package 
database or make a sample inno setup tool for the same thing.

just my 2c

lucio

>  
>