Keep group context between commands in repl 'state' ?

[asmodehn]

In my setup, it kind of makes sense to have one repl for one group with multiple commands.

In that usecase, I would like the group context (ie. options passed to the group, for all commands to use) to be kept in memory in the repl between commands... and also accessing it via a 'context' command.

Any advice on the proper way to do this without breaking click context handling ?

I am currently trying various things, as I couldn't find any documentation about that use case ( which seems quite intuitive, to me at least )

[untitaker]

Seems interesting. My first intuition is to try to launch another repl from within the repl. Not sure if that works.

…

On October 1, 2018 6:50:35 PM GMT+02:00, AlexV ***@***.***> wrote: In my setup, it kind of makes sense to have one repl for one group with multiple commands. In that usecase, I would like the group context (ie. options passed to the group, for all commands to use) to be kept in memory in the repl between commands... and also accessing it via a 'context' command. Any advice on the proper way to do this without breaking click context handling ? I am currently trying various things, as I couldn't find any documentation about that use case ( which seems quite intuitive, to me at least ) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #48

[asmodehn]

Let me try to iterate on that and hopefully make it clearer...
From a usage point of view, ideally I'd like :

$ my_click_mod.py --group_opt1 --group_opt2 command1 --cmd_opt1 --cmd_opt2
$ my_click_mod.py --group_opt1 command1 --cmd_opt1 --cmd_opt2
$ my_click_mod.py --group_opt1 command1 --cmd_opt1

To be equivalent as doing, in the repl :

> group_name --group_opt1 --group_opt2
> command1 --cmd_opt1 --cmd_opt2  # uses group_opt1 and group_opt2
> group_name --group_opt1
> command1 --cmd_opt1 --cmd_opt2  # uses group_opt1 but not group_opt2
> command1 --cmd_opt1  # still uses group_opt1 but not cmd_opt2

Differences I can spot with the current simple way to do things :

• group_name appears in the repl, similar as a command but affect repl "state"
• group options do not appear alone (ie with first group_name)
• we probably want a way to display the current state
  Problems : how to handle multiple groups ?
  Problems : how to handle modules using click commands importing other modules using click commands ?

OR (undecided)

group_name> reset --group_opt1 --group_opt2
group_name> command1 --cmd_opt1 --cmd_opt2 # uses group_opt1 and group_opt2
group_name> reset --group_opt1
group_name> command1 --cmd_opt1 --cmd_opt2  # uses group_opt1 but not group_opt2
group_name> command1 --cmd_opt1  # still uses group_opt1 but not cmd_opt2

Differences I can spot with the current simple way to do things :

• group_name gets into the repl prefix
• we need a special command / keyword (reset for example) to modify current group options / replstate
• group options do not appear alone (ie with first reset keyword)
• we probably want a way to display the current state
• typing another group switch to the repl for that group (with the other context).
  Problems : How to manage multiple groups, in a way compatible with click ?
  Problems : how to handle modules using click commands importing other modules using click commands?

In any case, it seems these would be useful:

• we need a special command / keyword (could be a keyword, maybe the group name) to modify current group options / replstate
• group options do not appear alone (ie with first reset keyword or group_name)
• we probably want a way to display the current state of the repl (maybe internal command ?)

I don't know if there is an easy way do any of these, other than modifying click-repl source ?
Thanks for the help.

[untitaker]

> group_name --group_opt1 --group_opt2
> command1 --cmd_opt1 --cmd_opt2  # uses group_opt1 and group_opt2
> group_name --group_opt1

In the third line, how do you know group_name is not intended to be a subcommand of command1? Unless you want to partially replace the click arg parser with your own you would need a way to exit a group state.

[asmodehn]

I would naively expect commands and all subcommands to be on the same call, ie. same line :

> command1 --cmd_opt1 --cmd_opt2 subcommandA subcmdA_opt1

What I had in mind was to have a "one repl <-> one group" relationship.
With only a 'one group has mutiple commands, sharing the same context' relation.

I have no idea however if, in click concepts, groups can be stacked up?

So given yourfeedback, the second option might make more sense :

group1> command1 --cmd_opt1

Note repls can be stacked up :

group1> command1 --cmd_opt1
group1> subgroupA --subgrpA_opt3
group1>subgroupA> sgA_cmd2 --opt5

So I was thinking of the stack of repls mirroring the stack of click contexts : ctx.parent.parent

As far as I can recall, currently if you call the repl from a group, there is a discrepancy between calling via command line, where you need to access ctx.parent in the command, and calling from the repl, where you need to access ctx.parent.parent.

Note that I don't think it would bring much value to have one repl per level of command / subcomands, as it would merely be a helper for option completion. I find the idea of using a repl to navigate the multiple commands available in a shared group context much more appealing...