[Distutils] project description files? (was: who needs keyword params?)

Greg Ward gward@cnri.reston.va.us
Fri, 4 Feb 2000 22:38:40 -0500


On 03 February 2000, Greg Stein said:
> I just had a reasonably evil thought. Looking at the above code, I
> thought, "man. look at all those parameters. gets kind of ugly. it would
> be nice to not have to pass all those, but just define them at the top
> level." Of course, that's when the anti-Pythonic demon possessed me, and I
> figured that we could do something like the following (untested) code:
[...evil code skipped...]

> Now that is fun! :-)
> 
> The only caveat is that any arguments passed to setup() must be keyword
> arguments -- it does not define any positional arguments (unlike the
> current setup function). Of course, this could be its "specification"
> and/or an extension of the above code could fix that.

<sarcasm degree="heavy">
Now Greg, I know you recently moved to California, but I don't know
where.  From reading that code, I'd have to guess you either live in
Mountain View, just down the street from a certain Mr. Wall; or you have
taken up residence in a low-rent district of San Francisco, and now
spend your time smoking crack in between "joke" posts to various Python
mailing lists.
</sarcasm>

<disclaimer tone="confessional">
In a past life, I wrote Perl code that did something rather like what
Greg's suggesting.  It wasn't quite so evil, though, since Perl has
a clearly understood "main" namespace in which "global global"
variables (as opposed to mere module globals) can be found.
It was handy, but I don't think I'm proud of it...
</disclaimer>

But seriously folks... I don't really care for the deeply nested data
structures you have to construct in order to specify a real-world set of
extension modules, either.  And I've been toying with some possible
"solutions" to the "I need to set compiler flags for individual source
files" problem that will only make things worse.

Now, you can always make things look nicer with some temp. variable
assignments just before the setup() call, eg.

  ext1 = ('ext1', { ... hairy build info dict ... })
  ext2 = ('ext2', { ... another hairy build info dict ... })

  setup (...
         ext_modules = [ext1, ext2]
        )

But that really only papers over the problem.

The thing that keeps hitting me on the head is "What are these deeply
nested data structure for?".  Well, they describe a project: in this
case, a set of Python extension modules.  So perhaps the answer is a
simple declarative "project description language".  Meaning that people
will have to write (simple declarative) "project description files"
along with their setup scripts.

Is this sounding to much like make-land for some people?  Or do you
think it's just the ticket?

        Greg