[Distutils] Random bits

[Michael Hudson]

On Thu, 2 Dec 1999, Greg Ward wrote:

> 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.

OK ... <sound of cute idea being sent to bin>.

> 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.

Fine. What are the problems with the current system? I know exclusion of
single files doesn't work, and you can provoke some dodgy looking
tracebacks with malformed MANIFESTs.

> 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.

My problem with this is that is a discontinous jump from the simple case
to the complex one - although as the other Greg pointed out, that's a hard
problem noone's got right, so just getting something that works for most
cases is a more important goal.

> > 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.

I certainly found it pleasant enough, MANIFEST nits aside.

> 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.

I would say it would be essential for 

python setup.py --help

to produce something more helpful than

option --help not recognized

I found the simple act of installing distutils somewhere other than
than the default to involve considerable head scratching and staring at
the USAGE file. I'd have thought this would be the commonest option passed
to install.

Regards,
Michael