Konubinix' opinionated web of thoughts

Clk Config per Level and Overriding

Fleeting

clk 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.