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@interlink.com.au> It's never too late to have a happy childhood.