[Python-Dev] Raising objections (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Thu Apr 20 07:53:55 CEST 2006

Anthony Baxter wrote:

It is precisely my concern that this happens. For whatever reason, writing packaging-and-deployment software is totally unsexy. This is why setuptools is a one-man show, and this is why the original distutils authors ran away after they convinced everybody that distutils should be part of Python. If distutils is now abandoned and replaced with something else, the same story will happen again: the developers will run away, Well, I've seen no indication that this is Phillip's plan. If it is, could he tell us now?

I don't know about Phillip's plans, but I do see many indications that people stop using distutils, and use setuptools instead.

People change their setup.py files to setuptools.setup instead of distutils.setup, since the former provides the same things to them, just better. So effectively, distutils disappears except as an implementation detail of setuptools.

There is much talk about backwards compatibility: these package are then, of course, not backwards compatible with earlier Python versions anymore. No problem: just install setuptools on these earlier versions. So distutils isn't just abandoned for the future versions, but also for past versions.

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.

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 is flatly not possible to "fix" distutils and preserve backwards compatibility.

Why?

Sometimes you have to rewrite. I point to urllib->urllib2, asyncore->twisted, rfc822/mimelib/&c->email.

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.

This approach means that people's existing code continues to work, there's a separate installer of the new code that is available for older versions of Python, plus we have the newer features.

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.

Regards, Martin

More information about the Python-Dev mailing list