[Distutils] Colour this bikeshed: Name for setuptools fork

P.J. Eby pje at telecommunity.com
Sat Jul 18 22:25:28 CEST 2009


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.



More information about the Distutils-SIG mailing list