[Distutils] Colour this bikeshed: Name for setuptools fork

[P.J. Eby]

At 07:39 PM 7/18/2009 -0700, Sridhar Ratnakumar wrote:
>PyPM currently uses `setuptools.package_index` in the backend mirror ..
>but that module is not very API-friendly (prints to stderr, throws
>network-related exceptions without handling them, and not flexible).

Yep, that's exactly the sort of thing I'd like to refactor.  (At 
least, the logging and flexibility bits -- it may actually delegate 
*more* error handling to the invoking application, for flexibility reasons.)

Anyway, splitting these things off into a separate package would 
certainly make it easier to keep the API clean, and clearly 
distinguished from any leftover legacy cruft.

As far as flexibility goes, the rough idea would be to have a 
PackageIndex be able to have  a custom logger and a "download 
manager", where the download manager's job is to vet URLs (e.g. 
filtering ala --allow-hosts) and to actually open/download 
URLs.  This would allow easier testing of the PackageIndex's main 
functionality, since a mock "download manager" could simulate 
downloads without actually downloading anything.

There would also be entry points for URL parsers (to figure out what 
distributions, if any, that URL might point to), index page readers 
(to handle specialized index pages like Sourceforge) and 
html-download handlers (to do things like detect an SVN, hg, git, 
bzr, etc. HTTP repository), as well as URL scheme handlers (to do 
e.g. svn checkouts).  All of the current cheesy special case code for 
these things would go away, replaced with independent functions or 
classes that simply act as plugins within the overall scheme.


>Eventually, if possible, I would like to add support for 'installing from
>source tarballs' (for packages that are not available in the ActiveState
>binary repository).

Certainly, between the .download, .unpack, and .sandbox modules, 
you'd be able to roll your own version of that, even if the .install 
module didn't include its own version.