[Distutils] Colour this bikeshed: Name for setuptools fork

[P.J. Eby]

At 01:05 AM 7/19/2009 +0200, Hanno Schlichting wrote:
>On Sat, Jul 18, 2009 at 9:50 PM, P.J. Eby<pje at telecommunity.com> wrote:
> > Also, this entire discussion may be moot if, as I'm currently understanding
> > it, this is simply a matter of other people doing maintenance and bug fixes
> > to the 0.6 branch... Â in which case there is a very strong 
> possibility that
> > I'll just bless various versions of it as official 0.6 versions of
> > setuptools.
> >
> > (One obstacle to this actually happening, though, is the part where they're
> > stripping out my release tools, like wikiup.cfg, version+version.dat, etc.,
> > as I would need to add these back in order to actually do a release.)
>
>In order to make it easier for you to bless things, I created a branch
>of our work, which very closely resembles the official setuptools 0.6
>branch, including the correct distribution name and including all your
>build and release tools.
>
>It's a "hg up -C setuptools-compatible-0.6" away after cloning the
>repo. It does need some more tweaks to version identifiers (is it 0.6
>or 0.6.0 or 0.6-final ...) and lacks the md5 checksums for release
>files, since these are obviously not produced yet.
>
>I'd be happy to produce the Windows binary installers for an official release.

Good to know.  I'll take a look at it soon.


>I'm sure we do have some disagreements about how to evolve setuptools
>after the 0.6 branch.

Perhaps.  But it occurs to me that there is something I can do to 
help that in the long run.  After giving it some thought today, it 
seems that it would be a good idea to take the "good" (i.e. 
relatively uncontroversial) parts of setuptools and split them out 
into another package, which I am tentatively naming "Discovery".

Rather than a set of executable tools, it would just be a collection 
of libraries to be called by package management tools, and other 
Python code needing to discover packages either installed on the 
system, on the package index, be notified when they're imported, etc. etc.

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

Then, easy_install could be refactored to consist mostly of calls to 
these other modules, along with whatever "legacy" logic needs to be 
retained for compatibility reasons, and setuptools proper could 
evolve towards just being build support, and become more pluggable generally.

It wouldn't be possible to switch setuptools to do this right away, 
since there would remain the problem of bootstrapping the 
installation of the discovery package prior to setuptools 
installation.  But setuptools' source distribution could perhaps 
bundle a copy of discovery within itself, and the ez_setup.py script 
could perhaps then be changed to download *discovery* first -- and 
then ask discovery to download setuptools to a temporary location.

However, now that somebody else is effectively looking out for 0.6 
maintenance, this lets me bump up the priority of working on 0.7, and 
has given me ideas for how to get out from under the rest of the 
"legacy" problems of setuptools, while also making reuse easier for 
competing and/or complementary projects (such as buildout, pip, etc.)