Hi K-T,

I guess the rest of DM will also need for some sort of configuration
so maybe this issue needs a wider discussion to set on something 
common? Or is it already decided and YAML is the only option for 
non-Butler (non-qserv) use?

Personally I have no direct experience with YAML. After reading all I 
can find I'm almost OK with YAML, the only thing that bothers me is 
Python-ish whitespace use for structure. Even with all the tools that 
we have for Python occasionally I find TABs in our Python code (used 
for indentation). I'm not sure how big of an issue this is going to 
be for YAML but I can imagine some surprises due to mis-indentation.

Using Python for configuration maybe attractive (and I know one major 
HEP experiment where it is done at large scale) but is probably 
overkill for us. We certainly need something that works from both 
Python and C++, this probably rules out Python as there is no easy 
way to access Python object from C++.

Cheers,
Andy


Kian-Tat Lim wrote on 2014-12-11:
> There has been discussion on DM-621 and its associated pull request
> about configuration file formats and parsers.  I'd like to try to bring
> this to a final decision.  This is not a formal DM RFC because (so far)
> this seems internal to Qserv.
> 
> The core LSST stack currently has two choices for configuration:
> pex_config or YAML.  (No one is using YAML yet, but the new Butler is
> expected to do so.)  (pex_policy is legacy and being removed.) For
> Qserv, I think pex_config is likely inappropriate, so I'm willing to go
> with pure execfile() Python (if you really need programmability) or YAML
> (if you need Python/C++ language independence).  From what I've seen,
> YAML is used in many places, has well-adopted parsers, has Mario's
> approval, and can do simple things simply.  You don't need to use every
> feature of YAML, and in fact I'd generally recommend against it.
> 
> If you'd like to use something other than the above, you'll have to show
> that those options are insufficient or that your other solution is far
> superior (not just marginally better).
> 
> I agree that migration to a new configuration file format should be
> another ticket, not part of DM-621.
>

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1