Clk Config per Level and Overriding
Fleetingclk config per level and overriding
Say I want to run
clk somegroup --someoption something somecommand
I want that in the context of running somecommand, clk parsed the option to have the value something
Guess I have another command called someothercommand that flow-depends on somecommand. Then I would call this.
clk somegroup --someoption something someothercommand --flow
During the parsing of the someothercommand, clk would remember that someoption is something. But when evaluating the flow, it would evaluate the command.
clk somegroup somecommand
We would expect that it remembered the someoption setting and run it like
clk somegroup --someoption something somecommand
In order not to pollute the config, when evaluating somecommand, a temporary config is generated, copied from the current config. Then the parsing appends the value of the parsed option (thus nothing) to the existing option (–someoption something).
Because it has saved the command line settings, it can evaluate
clk somegroup --someoption something somecommand
But doing so, because there may be several calls to ctx.make_context, we can append several time the same options and evaluate instead.
clk somegroup --someoption something --someoption something --someoption something somecommand
While this does not hurt in general, all the side effect (callback etc) that come with the option might go wrong at some point.
Also, since click-completion does not know about the temporary config, it makes use of several calls to ctx.make_context and ends generating buggy command line options.
For instance, the following does not work with this algorithm.
clk somegroup --someoption something --someotheroption <TAB>
It ends up trying to complete against
clk somegroup --someoption something --someotheroption --someoption something --someotheroption <TAB>
Messing up with the completion.
I need a mechanism to append the command line settings so that the flows, alias etc can behave appropriately while ensuring it is not appending too many times.
I suggest to have in the config a level_settings that is reset at each level. In this settings, I can record whether I did record the command line settings or not. I will be able to record anything that needs to be done only once per level in the future.
There are some times though when I explicitly want to have the side effects. Like when I parse some alias and want its parsing to impact my current settings.
clk alias set somegroup.somealias somegroup --someoption somecommand
Then I want that getting the alias behave like if I used
clk somegroup --someoption somecommand
And then, calling
clk somegroup --someotheroption somealias
Would first parse
clk somegroup --someotheroption
As parent of the alias
And then again
clk somegroup --someoption
When parsing the alias. Here I want to explicitly say that the second parsing appends on top of the first. And the command should behave like.
clk somegroup --someoption --someotheroption
To do so, I need that each time I want to run a context with side effect, I put aside temporarily the level settings, so that the side effect take place.