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.