stack-based configuration files road-map

[vila+bzr at canonical.com]

>>>>> Martin Pool <mbp at canonical.com> writes:

    > That sounds great.
    > The 'load it just once' probably means tying the configuration objects
    > to the library state object.

Yes.

    > One other thing has been on my mind, which is handling configuration
    > and isolation during testing:

Since they depend on BZR_HOME, that shouldn't be an issue.

    >  * in (nearly?) every case, we want tests to run totally isolated from
    > the configuration of the user running the tests; having all
    > configuration go through a single patch will let us clean up some code
    > that does that, but it also may mean the stack itself needs to be
    > isolated

Right, we miss a registry to acquire the stacks for a given context, I'm
working on that.

    >  * since the tests don't care about the user's configuration, they
    > don't really need to go to a file on disk

I'm not sure I follow here, tests have a isolated home directory so
they'll find their own config files (or not) there.

Are you thinking about a way to force a given option value for a test
(or a class/suite/run) ?

Like using a command-line option (http://pad.lv/491196) ?

    >  * it would be useful to have a clean way for tests to see what
    > happens when a particular value is configured

Yup. I'm still unclear on how we will use that but that's definitely
something I want to investigate.

    >  * some tests for configuration itself will be exceptions

What do you mean by configuration here ?