[Catalog-sig] Withdrawing PEP 262

[Aaron Sterling]

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

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

Aaron