At 01:05 AM 7/19/2009 +0200, Hanno Schlichting wrote:
On Sat, Jul 18, 2009 at 9:50 PM, P.J. Eby<[email protected]> 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.)
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
