[Python-Dev] Raising objections

[Phillip J. Eby]

At 10:39 AM 4/20/2006 +1000, Anthony Baxter wrote:
>On Thursday 20 April 2006 03:46, Martin v. Löwis 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 how widely the distutils were used *before* they became a part 
of Python, so it's possible the authors didn't know what they were in 
for.  Of course, it's still possible that I don't know what I'm in for 
either.  However, the amount of work I've been putting in wouldn't be 
possible without OSAF's indirect finanical support for the project.

But, setuptools solves problems that commercial entities are often 
interested in solving.  The Envisage folks inquired at Pycon about me 
possibly helping expand setuptools' scope to building and installing C 
dynamic link libraries, and this is also a feature potentially desired for 
Chandler's build system as well.

What this means is that there is a potential basis for supporting the work 
going forward, at least through what I'm hoping will be the "1.0" 
version.  And I suspect that there are other improvements possible that 
other commercial entities would be interested in funding.

How much any of that could have also applied to the distutils at one time, 
I don't know.  My point is merely that setuptools has enough commercial 
value to make me believe that sponsorship for features shouldn't be that 
hard to come by, and there are certainly worse things I could do with my 
work days.

This shouldn't be construed as saying I'll only work on setuptools if paid; 
it merely means that the huge gobs of time I've been putting into it at 
times are only *possible* because it aligns with OSAF goals enough to let 
me put a substantial chunk of my work days and nights into it.


>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. In addition, the existing
>distutils codebase is ... not good.

You know, after my experience doing setuptools, I'm a lot less inclined to 
criticize anybody's code, if it works and solves a problem.  Sometimes, the 
structure of the problems are just not amenable to beautiful solutions.  Or 
more to the point, beautiful solutions are not always economical to 
implement while you're supporting actual users and backwards compatibility 
is a constant requirement.  So my attitude to the distutils code has 
mellowed considerably; I view it as a collection of things that I at least 
don't have to think about.  C compilers, for example, are something I don't 
have to touch at all, except for some recent experiments in implementing 
shared library building.

So, I don't really view the distutils as broken per se; it's just that they 
lack a lot of desirable features that are hard to implement without 
breaking backward compatibility.  That's not quite the same thing as "the 
code sucks and we should rewrite it".  There have been a lot of calls to 
scrap it and rewrite it throughout the years I've been working on 
setuptools, but I can't imagine who could possibly *afford* such an 
undertaking (as opposed to talking about it).


>Yes. I remember that piece. In particular, he wrote the original rant
>about this about Mozilla/Firefox. How did that work out again? Oh,
>that's right - we now have a much, much more successful and usable
>browser.

Well, the analogy isn't great anyway, because setuptools is hardly a 
rewrite of the distutils.  I didn't rewrite a single thing I could get away 
with calling or subclassing.  Setuptools is all about adding new features, 
not "cleaning up" the distutils code base, so arguing about whether 
rewrites are good or not is a straw man holding a red herring.  :)