>Heh... so...
>1: If I read that right, now the configs for virtualization and network will live in /etc/xdg/plainbox.conf. Did you add the default configs there? (I don't see it in this diff)

We don't create plainbox.conf by default in any of our packages, but this is a good point. I'll see if it makes sense to ship this file in one of the packages (I'm thinking plainbox-provider-checkbox).

>2: Personally, I think the separate files is a bit more intuitive as it says (Hey Tester, edit these files here for network and virtualization tests)

I agree in principle, we decided against having script-specific config files because it felt a bit kludgy, but we can also try to think of a way to do this. The naive way is to just have the scripts search in /etc/xdg as well and have plainbox-provider-checkbox install the existing configs in there, but that's just relocating and doesn't feel like it solves the issue entirely.

>3: /etc/xdg/plainbox.conf is harder to find than /etc/checkbox.d was but that's a minor quibble

that's just because the tool was called checkbox :D. If the new tool is called canonical-certification-server the equivalent would be some sort of /etc/canonical-certification or some other such.

>4: What's the order of precedence for environment variables now? they don't override command line, yes, but do pre-set env vars override the ones read from plainbox.conf? (e.g. if I have TARGET set already via the shell, will running plainbox overwrite TARGET with whatever is in plainbox.conf?)

PLainbox's env-setting magic will always give precedence to the actual environment, so in your example, no, whatever you set in the shell for TARGET would be authoritative.

>5: has this been tested with the contents of the network.cfg and virtualization.cfg included in plainbox.conf?

I didn't :/ I tested with some dummy values, I checked all possible sequences (setting env in the shell, setting env in the config file, using command-line) and in all cases it picked up the correct values. But again, I didn't just translate the existing values to equivalents in plainbox.conf :( sorry, my bad.

>6: the pep8 fixes made the diff rather hard to read, it's hard to tell what is related to this fix and what is pep8 adding spaces or doing something that doesn't really affect the script.

Yes, that's always the case when reading the complete diff on launchpad :( The pep8 fixes are in a separate commit though, so you could bzr branch and review locally, or check each individual commit in the branch (https://code.launchpad.net/~roadmr/checkbox/1260507-config-files). The meat is in commits 2626 and 2628; 2627 is just documentation and licensing stuff, while 2629 are the pep fixes.

OK, actions that will result from this comment: 

- Find a good place/way to create an example/prepopulated plainbox.conf.
- Retest this mechanism with the existing values from checkbox.d to ensure they work and make sense as they did before.

We need to decide:
- Do we want to somehow split again these config files? If so, how to do it without simply relocating them, which would be a bit kludgy?
- Do we want to somehow place these files in a more-intuitive config directory that refers to the tool that will use them? Just keep in mind that these tests may be used without canonical-certification-server; e.g. a person installing plainbox, plainbox-provider-checkbox and e.g. my-cool-test-client will be as baffled by /etc/canonical-certification-server as they would be about /etc/xdg/plainbox.conf.