stack-based configuration files road-map

[Martin Pool]

On 11 August 2011 23:37,  <vila+bzr at canonical.com> wrote:
>>>>>> 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.

It will be for the system-global file that Grid is adding.


>
>    >  * 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) ?

I was thinking that it's just inefficient to do disk IO when we know
there's nothing interesting there; but obviously this is not urgent.
>
>    >  * 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 ?

Tests that the configuration stack really does go to disk, to the
user's directory, etc.

Martin