[Distutils] Random bits

[Greg Ward]

On 02 December 1999, Greg Stein said:
> On Thu, 2 Dec 1999, Michael Hudson wrote:
> >...
> > class Acceptor:
> >     def __and__(self,rhs):
> >         return AndingAcceptor(self,rhs)
> >     def __or__(self,rhs):
> >         return OringAcceptor(self,rhs)
> >     def __neg__(self):
> >         return NotAcceptor(self)
> 
> Sorry... but this is just silly. This is taking a simple problem of file
> selection and throwing a mess of procedural code at the thing. How is this
> *any* better than a simple list of files or file patterns?

Once again, I completely agree with Greg here.  Michael's scheme is,
ummm, interesting, but there is such a thing as being *too*
object-oriented.  I have not paid a lot of attention to performance in
the Distutils, but I draw the line at severl method invocations to test
every file in the source tree.

The MANIFEST.in file should provide the level of flexibility needed by
that all-important 80% of distributions.  I think it's close now, but
the syntax is inscrutable and the implementation flaky.  (And it doesn't
use MANIFEST.in, just MANIFEST.)  The point of this thread is to fix
those problems, not come up with an entirely different scheme.

The distutils have been designed so that if a module developer *does*
need some totally custom way to specify what files belong in his source
distribution, it's not a problem.  In theory, it goes something like
this:

  * write a class that subclasses distutils.command.dist.Dist
  * override the method that finds the files to distribute
  * tell 'setup()' to attach your new class to the "dist" command
    rather than the default, distutils.command.dist.Dist

and Bob's your uncle.  (Disclaimer: this has never actually been tried
in practice.  It's a lovely design, though, if I may so so myself.)

Another wee nit is that the Dist class as currently implemented has
*two* methods for finding all files, which makes overriding slightly
awkward.  So sue me.

> The distutils package must be *very* simple to gain acceptance. Requiring
> people to write code, understand how to subclass CCompiler, or provide a
> bazillion params to a setup() function is just not going to help.

I think it's getting there for module developers.  The setup.py for
Distutils itself is as simple as I can imagine it being.  The three
example setup.py's included in the distribution (for PIL, mxDateTime,
and Numeric) are a tad more verbose than they really need to be --
there's a bit too much bureaucracy involved in specifying how to build
simple extension modules.  That's definitely fixable, though, and once
it's fixed I'll be very happy with the developer interface.

The end-user interface is still a bit clunky because I picked some bad
names for installation directory options, and some of the semantics
behind certain options are mildly bogus.  (Needs a bit more do-what-
I-mean-not-what-I-say logic, which must be doled out with care but can
go a long way in this sort of thing.)  The bogosity was only revealed as
I wrote the documentation (and the IPC8 paper on the Distutils), and I
haven't touched the code since then.  But these problems are on my
mental to-do list.

> Grain of salt time: until I step up and provide code to make distutils as
> simple as I hope it would be, my comments should be viewed as "peanut
> gallery" comments.

Hey, toss all the peanuts you like.  My hide's not quite as thick as an
elephant's, but so far nothing on this sig has offended me too deeply.

        Greg