CPAN functionality for python

ssthapa at classes.cs.uchicago.edu ssthapa at classes.cs.uchicago.edu
Mon Feb 12 16:03:39 EST 2001


Sean Reifschneider <jafo at tummy.com> wrote:
>The first question I would ask is: is there any way we can leverage
>the work done by the Trove project?  I really don't know the status
>of that project though.  Eric?  Any way to leverage off the work done
>by CPAN?  Trying to leverage off existing art is a good idea, but I
>don't think that dpkg is the right sort of tool for it.  If the
>system could integrate with dpkg, rpm, swinstall, great!

  I'm not familiar with Trove, what is it? It would be difficult 
to integrate this system with dkpg, or rpm.  At the very least, it 
would involve creating dummy packages.  
  I've taken some of CPAN's ideas as inspiration while writing my code
but I'm not sure how much more help CPAN can be outside as being an example
of a similar system.

>For example, you may ask about "filterinput", and it would report
>that there are versions X and Y and Z.  Then you'd ask where to find
>"filterinput" version X and it would give you a list of URLs that
>have it (or the like).  Ideally, you'd then be able to send a light-weight
>packet to the servers listed asking about their willingness to provide
>that resource, but that could be optional.  It would be nice to be
>able to easily prune out the mirrors that were already at capacity,
>no longer had that file or that version, etc...
  
  Parts of this are already implemented, e.g. the config file lists 
a group of mirrors and the script will try to grab the file from one and will
move on to the next if its connection is refused.  I guess an extension to 
this would be randomize which server is choosen or to allow the mirrors
to have preferences associated with them.  However, at the moment the 
program uses ftp to grab the files but a new module implementing a different
method wouldn't be hard to add.

>ESR dismissed it because it wasn't really possible to do with a regular
>web or ftp client.  However, if we're probably going to have our own
>client anyway (a browser isn't likely to be able to install the software
>once it's downloaded).
>
>The problem of finding a mirror that's still got the file and isn't
>overloaded is certainly not getting any better though.

  With a conventional ftp client,  this is sort of doable.  If you let
administrators place a dummy file in the archive that indicates that this
mirror is overloaded, then you can get a crude way of skipping loaded servers.

-- 
----------------------------------------------------------------------------
	   		              |
Suchandra Thapa                       | "There are only two kinds of math . 
s-thapa-11 at NOSPAMalumni.uchicago.edu  | books. Those you cannot read beyond 
			              | the first sentence, and those you 
			              | can not read beyond the first page."
			              |                     -C.N. Yang
----------------------------------------------------------------------------



More information about the Python-list mailing list