[Python-Dev] Raising objections

["Martin v. Löwis"]

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? <wink> 

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