[Distutils] Colour this bikeshed: Name for setuptools fork

[Sridhar Ratnakumar]

On Sat, 18 Jul 2009 19:31:36 -0700, P.J. Eby <pje at telecommunity.com> wrote:

> The package itself would look something like this:
>  discovery.resources -- basically pkg_resources under a different name
>  discovery.sandbox -- basically setuptools.sandbox, less distutils  
> dependency
>  discovery.unpack -- setuptools.archive_util, less distutils dependency
>  discovery.downloads -- a hugely refactored version of parts of  
> setuptools.package_index, redesigned for pluggable extendibility (e.g.  
> to handle Sourceforge crap, checkouts from other revision control  
> systems, etc.)
>  discovery.install -- selected subroutines from easy_install, refactored  
> for narrow functionality and minimal coupling, combined with PEP 376  
> support code
>  discovery.importing -- basically peak.util.imports under a different  
> name, but with a more modern/decorator-friendly API
>  discovery.plugins -- basically peak.util.plugins, refactored to drop  
> dependencies on other PEAK modules

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

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

So, +1 on discovery.downloads (our backend mirror) and  
discovery.sandbox/resources at least (the idea being to co-operate with  
both activestate repo binaries and easy_install'ble tarballs).

-srid