[Python-Dev] setuptools in 2.5.

[Guido van Rossum]

Thanks for posting an excellent summary, Anthony.

For the record, I'm taking full responsibility for the decision that
setuptools is going in. Having read much (though not all) of the
endless bitching, and the responses from Phillip and others in
defense, I still believe it's the right decision. I've learned my
lesson about discussing library additions early -- I didn't anticipate
any controversy on this one.

The way I see it is this: a distribution tool that handles
dependencies and other problems that distutils doesn't solve is sorely
needed; blessing a particular solution makes a huge difference in
acceptance, and acceptance is key for a distribution tool; setuptools
is pretty much the only available candidate (platform-specific tools
don't count).

So I'm blessing setuptools. I'm sure Phillip will fix the remaining
issues enumerated by Anthony below, and any new ones that might come
up during the release cycle. Please help by being constructive in your
criticism. Bug reports are useful. Whining is not.

--Guido

On 4/20/06, Anthony Baxter <anthony at interlink.com.au> wrote:
> 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.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)