 |
 |
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