[Python-3000] Proposal: No more standard library additions

[Phillip J. Eby]

At 06:21 PM 10/16/2006 +0200, Martin v. Löwis wrote:
>Ronald Oussoren schrieb:
> >> And indeed, distutils already has support for that:
> >> distutils.dep_util offers a couple of routines that
> >> do time-stamp checking.
> >
> > This points to at least part of the problem: there is very little useful
> > documentation on how to extend, or even use, distutils.
>
>Thats certainly the case, and indeed a problem (I readily
>admit there are many problems with distutils). These problems
>can only be fixed through people contributing documentation,
>though. This *specific* problem certainly cannot be resolved
>by replacing the package with something else, unless that
>something else has already excellent documentation to start
>with (which it likely doesn't).

One nice thing about zc.buildout in this respect is that its tutorial is 
part of its doctest suite.  The more-complete dependency framework offered 
by zc.buildout also highlights another aspect of the problem: saying that 
you can create a useful build system from distutils.dep_util is like saying 
you can create one using the standard library.  There's only about 40 lines 
of actual code in that module, and it's hardly rocket science.  Meanwhile, 
most of the routines have some flaws for being used as anything resembling 
a "make" facility; for example, newer() and newer_pairwise() raise 
DistutilsFileError if a source file is missing!  This is a minor example of 
what I mean about distutils often encoding high-level policy assumptions 
into low-level routines.  Its "util" modules aren't really suitable for 
reuse by anything but the distutils, and you can't change them without 
breaking the distutils.

('newer_group()' is better for reuse than its neighbors, of course, but if 
one were writing new code, there would still be little gained by borrowing 
this brief routine, assuming that you even knew it existed, given the 
undocumented nature of the module.)


>I believe that the whole issue of packaging and deployment
>is indeed one of the biggest challenges in IT engineering,
>so it is no surprise that the technology attempting to deal
>with it is complex, incomplete, and non-intuitive. And that
>statement is IMO not only true about distutils, but also
>about its direct competitors,

What competitors?  Do you mean Ruby gems, CPAN, etc.?  I would say that 
those competitors actually show that we could do much better than we 
are.  I think that Perl may actually have us beat in terms of having "one 
way to do it" with respect to package layout, for example.  (Ah, the irony, 
given the Perl TMTOWTDI motto, and our own "There should be one and 
preferably only one obvious way to do it.")