[Distutils] Colour this bikeshed: Name for setuptools fork

[Tarek Ziadé]

On Sun, Jul 19, 2009 at 4:31 AM, P.J. Eby<pje at telecommunity.com> wrote:
> [...]
> 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.)
>

That's very interesting but you previously said that you needed time
and/or someone
paying you to continue the work in this area. And that you didn't have time
so setuptools was just "sleeping" (that's your own word)

Now, suddenly, you want to do what we planned to do in Distribute 0.7,
e.g. splitting
setuptools in several packages.

That would be nice but I am a bit surprised, and very suspicious in fact.

I am scared that at the end, you will still lock us by not blessing
people to maintain
yet another collection of packages you don't have time to maintain.

So, I am glad that our fork made you think about your future plans, but unless
you give us some guarantees, I don't see anything changing. And I'd prefer not
relying on you for this because you have proven with the past year
you didn't have time at all to work on the code.

So are you willing to bless us maintaining/working with you with these
new packages,
or is that going to be a PJE-locked thing again ?

If this is not stated clearly, Distribute will probably compete with
your new "Discovery" packages
I am afraid.

Now for the packages, they all look great

just a question :
> discovery.unpack -- setuptools.archive_util, less distutils dependency

how this will be 'less distutils dependent' ? because I was planning
to integrated setuptools.archive_util in distutils.

Regards
Tarek