[Python-Dev] setuptools in 2.5.

[Anthony Baxter]

In an attempt to help this thread reach some sort of resolution, 
here's a collection of arguments against and in favour of setuptools 
in 2.5. My conclusions are at the end.

The arguments against:

 - Someone should instead just fix distutils. 

   Right. And the amount of yelling if distutils changed in a non-b/w 
compat way wouldn't be high. There's also the basic problem that the 
distutils code is _horrible_. 

 - It monkeypatches pydoc and distutils!

   It only monkeypatches pydoc when the separate setuptools installer 
is used on older Pythons. How is this relevant for this discussion of 
Python 2.5? The monkeypatching for distutils should be reduced - see 
AMK's message for a breakdown of this.

 - Documentation

   beaker% pydoc xmlcore.etree
   no Python documentation found for 'xmlcore.etree'

   beaker% pydoc ctypes
   no Python documentation found for 'ctypes'

   The documentation (of which there is plenty) can and will be folded 
into the standard python docs. Most of the new modules in 2.5 went in 
before their docs. 

 - Where's the PEP?

   I don't see the need. The stuff that could go into a PEP about 
formats and the like should go into the existing Distutils 
documentation. It's a far more useful place, and many more people are 
likely to find it there than in a PEP.

 - It's a huge amount of code (or "ball of mud"), or, it adds too many 
features.

   Most of these have been added over the last 2 years in response to 
feedback and requests from people on distutils-sig. There's been an 
obvious pent-up demand for a bunch of this work, and now that 
someone's working on it, these can get done.

 - It will break existing setup.py scripts!

   No it won't. If you don't type the letters 'import setuptools' into 
your setup.py, it won't be affected. 

 - Rewriting from scratch is bad

   This isn't a rewrite - it's built on top of distutils. 
(An aside, I don't buy the "never rewrite" argument. As I mentioned in 
an earlier message, look at urllib2, twisted and email for starters. 
In addition, look at Firefox, Windows XP, and Mac OSX. Hell, Linux 
could be considered a rewrite of Minix, once upon a time.)

 - Eggs are inferior to distribution-specific packaging

   Not all operating systems have a decent packaging system. The ones 
that do, don't support multiple versions of the same library. In 
addition, there's no reason why existing packaging systems can't just 
bundle up the code as they do now - if they also add a .egg-info file 
to the packages, that would be even better! Finally, these don't 
support user installation of software. This is particularly useful in 
a hosting environment. 


And now let's look at some of the stuff that setuptools gives us:

 - We have a CPAN-type system

   I do quite a number of Python talks, and this is _always_ one of 
the most requested features. There's been many attempts to write this, 
none have been completed until now. If you honestly don't see that 
this is a big thing for Python, then I am very, very suprised. I 
suspect that this will be the #1 new feature of Python 2.5 that the 
users will notice and be happy about.

 - Multiple installs of different versions of the same package, 
including per-user installs. 

   Again, as Python gets more widely used, this becomes a big issue.
Sure, it's not necessarily a killer argument for python-dev, but stuff 
that's added to Python shouldn't just be just for the use of 
python-dev. The multiple installed versions feature also avoids the 
CPAN dependency hell problem - back when I used to work with Perl, 
this was a constant source of nightmarish problems. 

 - The "develop" mode

   This makes life that bit less painful all-round. 

 - The plugin/extension support

   Extending distutils currently is a total pain in the arse. 

 - Backwards compatibility

   easy_install even works with existing packages that use traditional 
distutils, so long as they're in the Cheeseshop. Damn, this is nice. 
If you don't want to do the work to change your installation code, 
don't bother - it will still be useful. 

The conclusions:

I'm a little suprised by the amount of fear and loathing this has 
generated. To me, there are such obvious benefits that I don't see 
why people are so vehemently against setuptools. I haven't seen any 
arguments that have convinced me that this isn't the right thing to 
do. Yes, there's still work to be done - but hell, we've only 
released the first alpha so far.

For inclusion in the standard library, the usual benchmark is that the 
code offers useful functionality, and that it be the "best of breed". 
setuptools clearly meets these two criteria. (Ok, it's really "only of 
breed", but that also makes it "best", by default <wink>). It's also 
been under development for over 2 years - according to svn, 0.0.1 was 
checked into svn back in March 2004.

I'm also suprised by how much some people seem to think that the 
current state of distutils functionality is acceptable or desirable. 
It's not - it's a mess. 

Finally, I'd like to point out that I think some of the hostility 
towards Phillip's work has been excessive. He's done an amazing 
amount of work on this (look at the distutils-sig archive for the 
last two years for more), and produced something that's very very 
useful. 

He deserves far more credit for this than he seems to have been 
getting here.

Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.