jessenoller.com

So, I find myself using more and more YAML lately via the pyyaml pack­age. When I was writ­ing nose-testconfig my “pre­ferred” for­mat was/is YAML.

Now, an inter­est­ing thing I’ve noticed about all of the test con­fig­u­ra­tions I am developing/working with is that they have a lot of “shared” attrib­utes (that change infre­quently) and a good num­ber of things which change all the time.

This is the per­fect spot for some­thing like a dic­tio­nary merge. If you have a test con­fig like this:


application:
capability: 1
url: http://foo
subsystem:
max_users: 20


For each of your con­fig­u­ra­tion files, you might only over­ride some­thing like, max_users. For cases like this, it makes sense to load the tem­plate doc­u­ment (the file above) and then per­form a dict.merge() after load­ing the sec­ond doc­u­ment (over­rid­ing the val­ues in the first load) or some­thing akin to that.

This is where my men­tal dilemma comes in. I could in the­ory, add a cus­tom !!tag to the yaml which would take a /path/to/file.yaml and load it first, then load the sec­ond doc­u­ment or I could do it within nose-testconfig where you might run:


nosetests . --tc-file=myconfig.yaml --tc-rootconfig=parent.yaml


And then I would jump through the hoops (with a merge prob­a­bly) within the plu­gin. The prob­lem with that is that I’m wor­ried about cou­pling the plu­gin too closely to yaml.

Now, the plu­gin already sup­ports over­rid­ing mul­ti­ple val­ues: How­ever, this doesn’t scale if you have to over­ride a lot of them.

The most com­mon rea­son I’ve found for this so far is adding new para­me­ters and val­ues to the YAML files — not all child con­fig­u­ra­tions need to override/define the new val­ues, instead they could just inherit from the parent.

So, the ques­tion is — how do (would) you do this so you:

• Don’t sac­ri­fice clarity/readability
• Scales
• Doesn’t require the root doc­u­ment to be in the same loca­tion or have a hard coded path in the child document
• Doesn’t cou­ple the loader (nose-testconfig) tightly with the file format

Right now, it’s copy, paste, edit all con­fig­u­ra­tion files I know about, etc.

So, I find myself using more and more YAML lately via the pyyaml package. When I was writing nose-testconfig my "preferred" format was/is YAML. Now, an interesting thing I've noticed about all of the test configurations I am developing/working with is that they have a lot of "shared" attributes (that change infrequently) and a good ...