[Python-Dev] setuptools in 2.5. (original) (raw)
Anthony Baxter anthony at interlink.com.au
Thu Apr 20 06:56:07 CEST 2006
- Previous message: [Python-Dev] bug with __dict__?
- Next message: [Python-Dev] setuptools in 2.5.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 ). 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.
- Previous message: [Python-Dev] bug with __dict__?
- Next message: [Python-Dev] setuptools in 2.5.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]