At 04:54 PM 7/18/2009 +0200, Joachim König wrote:
I think this is the main issue with setuptools: it requires
maintainers capable of mastering a high
degree of complexity.
That's because:
1. It started as some project-specific distutils hacks to make life easier,
2. It got a whole bunch of new hacks added on to support eggs and
automated installation, and
3. The distutils were already way too f'ing flexible. A ridiculous
amount of setuptools' complexity stems from trying to be 99% backward
compatible with the bizarre configurations that distutils allows.
- upsettools because it upsets a lot of people
I actually like that one, and if this project doesn't use it, I will
probably steal it for something else of my own at a future date. ;-)
Can't setupstools be split up into individual scripts that can be
used on their own but working
on a common specification:
- determining dependencies
- determining what's installed and detecting possible conflicts
These two are in the pkg_resources module...
- fetching code from remote to the local system
...the setuptools.package_index module...
- extracting the code for building
- patching the code with local patches
- building the code
- installing to the destination
...and the setuptools.command.easy_install module (except for the
patching part). So there is already a good degree to which these can
be split out and reused for another project.
The only reason why all this stuff is bundled in a single setuptools
distribution is simplicity of bootstrapping. If pkg_resources and a
cleaned-up version of setuptools.package_index were in the stdlib,
then other distribution tools could build on them without needing to
bundle them.
OTOH, maybe part of what we need is better tools for bundling on the
build side, so that packaging tools could just throw a few .egg or
.zip files into their sdists for bootstrapping support. That'd
probably be even more useful than an improved download-and-bootstrap
facility, at least for packaging tools.
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
