[Python-Dev] Raising objections

[Anthony Baxter]

On Thursday 20 April 2006 15:53, Martin v. Löwis wrote:
> I don't know about Phillip's plans, but I do see many indications
> that people stop using distutils, and use setuptools instead.

Surely that's an indication that it _should_ become part of Python? If 
there's an obvious demand for the features.

In addition, it's available for 2.3 and 2.4 as a separate package.

> > I started looking at this. The number of complaints I got when I
> > started on this that it would break the existing distutils based
> > installers totally discouraged me.
>
> I believe this is a myth. Some changes might cause breakage, yes,
> but others wouldn't. For example, introducing additional parameters
> to setup is just fine: existing packages won't break; new packages
> using these parameters won't build on older Python releases, of
> course.

Something as simple as replacing the distutils.fancy_getopt with 
optparse couldn't be done in a completely backwards compatible way, 
because of some of the funkiness in fancy_getopt that people use 
today. 

> > In addition, the existing distutils codebase is ... not good.
>
> Then it shouldn't have become part of Python in the first place.
> Can you please elaborate what specific aspects of distutils
> you dislike?

It's extremely awkward to plug in functionality that _should_ be more 
obvious and extensible. At least, unless you want to make every 
single setup.py include a magic bit of patching to Do The Right 
Thing. 

There are a number of places where the code is obviously not finished, 
when Greg clearly got fed up with the project <wink>. There was no 
decent documentation of the internals. 

> > It is flatly not possible to "fix" distutils and preserve
> > backwards compatibility.
>
> Why?

Because there are too many people that have poked too deeply into the 
innards with their setup.py scripts. Partly this is a function of the 
lack of documentation - until I sat down and spent a couple of days 
on it a year or so ago, there wasn't a library reference. There's 
still no decent "here's the Approved Way to poke about inside 
distutils" doc. 

> If I had the time, I would question each of these. Yes, it is
> easier for the author of the new package to build "in the
> green", but it is (nearly) never necessary, and almost always
> bad for the project.

I guess I disagree almost entirely. The new email package is vastly, 
vastly better than the old hodge-podge of stuff that was written back 
in python's Dark Ages. Trying to fix those would have been almost 
impossible. In addition, we'd be stuck with the need to maintain 
backwards compatibility. Something like spambayes or almost anything 
else handling modern email traffic would then not be possible in 
Python. 

> Yes, and everybody has to rewrite their code, because the "old"
> modules don't see fixes, and get obsoleted and eventually removed.
> Users get the impression that Python breaks their APIs for no good
> reason every now and then.

distutils doesn't _get_ fixes. Well, hardly any. Compare that to a 
'svn log' in sandbox/setuptools. I know I much prefer an actively 
maintained and developed codebase to some ancient but inert existing 
system. Heck, most of the recent work on distutils was an offshoot of 
setuptools.

As far as "breaks their APIs" - this is a pretty rare occurance, it 
might have happened half a dozen times so far. And the old module 
still keeps working fine. If there's bugs that someone logs, they 
will get addressed exactly the same as any other bug. I don't see 
people closing patches off as "that's an old module, I'm not going to 
apply it". It also takes _years_ for older modules to go through the 
process of deprecation, moving to lib-old, and final removal. I mean, 
heck, rfc822 still doesn't issue any deprecation warnings. I suspect 
C++ or Java change faster <wink>.

Anthony

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