On Wed, May 4, 2016 at 3:28 PM, Paul Moore <p.f.moore@gmail.com> wrote:
so it could be purely declarative, but users could also put code in
On 4 May 2016 at 23:11, Chris Barker <chris.barker@noaa.gov> wrote: there to
customize the configuration on the fly, too.
That basically repeats the mistake that was made with setup.py. We explicitly don't want an executable format for specifying build configuration.
I don't think it's the same thing -- setup.py is supposed to actually CALL setup() when it is imported or run. It is not declarative in the least. what I'm suggesting is that the API be purely declarative: "These values will be declared" (probably a single dict of stuff) but if you make it an executable python file, then users can write code to actually create their setup. Alternatively, you make the API purely declarative, and then folks have to write external scripts that create/populate the configuration files. I guess where I'm coming from is that I'm not sure we CAN make a purely, completely declarative API to a build system -- folks are always going to find some weird corner case where they need to do something special. making the configuration file executable is an easy way to allow this. Otherwise, you need to provide hooks to plug in custom functionality, which is jsut alot more awkward, though I suppose more robust. I've found it very handy to use an executable python file for configuration for a number of my projects -- it's really nice to just throw in a little calculation for something on the fly -- even if it could be done purely declaratively Anyway, if you stick with purely declarative, you can still use Python literals as an alternative to JSON (Or INI, or, ....). Python literals are richer, more flexible, and, of course, familiar to anyone developing a python package :-) -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov