On Sat, 18 Jul 2009 19:31:36 -0700, P.J. Eby <pje@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