[Catalog-sig] Withdrawing PEP 262

[Chris Liechti]

Am 14.10.2002 21:36:42, schrieb Aaron Sterling <AASterling@hotpop.com>:
>10/13/2002 5:55:56 PM, Chris Liechti <cliechti@gmx.net> wrote:
>>i admit that i'm less interested in an installed files database (within python)
>>rather than in a good way to download modules from a repository.
>
>That is my view as well, I also agree with you implication that for the second to be done 
>well the first must be in place.
>
>>if there was a browser that lets one select the extensions one wishes and
>>then just press OK, that would be great. (maybe that could even be called
>>within a running python application to request the user to install an addon.
>>run in a separete process to solve the problem with different GUI systems)
>>
>>i think it would be a pythonic solution when that browser would integrate
>>with the systems package manager. as a fallback it could still use
>>"setup.py install" (loosing remove capability but that's not too important as
>>systems without a package manager have a mess anyway ;-)
>>
>>that would mean that there must be a repository of modules (at python.org?)
>
>Perhaps a good way to do it would be to have a table that can be easily downloaded at 
>python.org. The table would consist of package name in one coloumn and the direct url/s
>(suitable for automatic download) of the resource as the other coloumn. If the desired module 
>is not available from any of the given urls, their could be a repository of the more 
>frequently used/standard library modules at the site to be downloaded as a last resort.
>The table could be included with the standard library and accessed on the website if the 
>local copy were six months (I pulled it out of the air, it could be any age) old or older. It 
>would also be accessed when the local copy did not contain the required module. It could then 
>be stored as the new local copy until a new copy was required according to the specified 
>material. This scheme would have the advantage of saving bandwidth on the python website.
>
>An alternate way to do it(and a much cooler way of doing it in my book), would be to select a 
>port on the python.org site and attach a server to it for a very simple protocol that could 
>be developed and implemented in about half an hour. The server would simply recieve the name 
>of the desired package and dispatch the url from which it could be downloaded.

no no...reason: firewalls. there must be a way to access the list through a http proxy when no other
protocols are passed trough a firewall (i have this situation where i work). because of that i'd say
the priorites should be the following 1. http, 2. ftp, 3. custom protocol,if any.
an another good reason: standards like a web server are easier to use. it's easy to convince
the IT departement that they should open a directory for the module repository while it is likely
to be very difficult to convince them to run a special server app.

look how Debian is working. there is a Packages.tgz on the server with a list of the available stuff.
and it can be accessed throught htpp and ftp, realy easy and just working.

> This would 
>have the advantage of allowing the server to keep track of requests for packages, thus 
>allowing usage data to be collected(or not). This could be used to decide which packages to 
>add to the standard library. Adding the most frequently used packages to the standard library 
>would have the effect of cutting bandwidth use on the server. Like the first solution, the 
>table would also be maintained locally and the main table at the website would only be 
>accessed under conditions similiar to those in the first solution. It also goes without 
>saying that the code to do these things would be a package so that Large organizations would 
>be able to run their own package servers. ImportError could even be changed in such a manner 
>that(at the administrator/users discretion for obvious security reasons) if a required 
>package was not on the system, it could be downloaded and installed automatically. That would 
>be cool(Is their a programming system that provides that functionality now?). Security 
>concerns could be overcome to some degree by having automatic installation download 
>exclusively from the python.org website.

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

>for either solution new submissions would be added by mailing the name of the package and the 
>url to a specified mailbox at the website. A simple script could add them on a daily basis. 

i think there should be two categories. one trusted, where the submissions must be signed and
go through some process where different people can look at it and a second easy to upload
repository, so that the number of packagaes can quickly grow. the quality of the submissions will
be lower in the second one but there might be some pearls...

>I think that the first plan is definitely doable, I favor the second(I know my voice carries 
>no weight). It goes without saying that somebody will think that the second solution is 
>overkill, but is that the general concensus?
>
>If --any-- intererest whatsoever is expressed in either of these plans, I would be more then 
>willing to further flesh them out or work with anyone on further fleshing them out, in fact I 
>am fleshing the second one out at the moment.