On 05 February 2000, Greg Stein said:
Ack! I thought we threw out the "new little language" a while back.
But if you insist, maybe there is a way to break down the structure into something that fits nicely with ConfigParser? For example:
For some reason, it keeps coming back to haunt me. I am not a big fan of little declarative languages, but sometimes they can be useful. Eg. for the limited range of tasks to which make is well-suited, I would much rather write a makefile than a Python script. The problem is that most such little languages give you no good way to break out; make at least gives you *a* way (shell commands), but no one would call that a *good* way. (GNU make gives you a few more ways [various forms of access to the external environment when defining variables], but again that'll only go so far until you hit the usual brick wall endemic to special-purpose languages.) I find Anthony Pfrunder's Zmake intriguing -- the idea is basically makefiles with Python code instead of shell commands. I just don't know the right way to integrate it, or any other little declarative language for that matter, into the Distutils' way of doing things. I'll continue to toy with the idea, and I'm certainly open to entertaining others' ideas.
[global] target = ooky
[ext1] flag1 = foo modules = bar, baz
[ext2] flag3 = bogle ...
Then use "setup(conf='project.conf')".
Of course, this throws out all possibility of computed values, which is why we kept the config "language" in Python. You could state that the .conf file is used IFF the corresponding parameter is not provided to setup().
That just might work. The idea of section headers being dynamically determined by the nature of the current module distribution (is "ext1" present or not?) seems a tiny bit dangerous; somewhere down that road lies the madness of programming languages with dynamic syntax. But the ConfigParser syntax is so simple I don't think this minor abuse could be carried very far. Greg