Session templates in shpool list --json; configure templates in shpool config; variable presets

[GeoffChurch]

#357 added session name templates.

This opens up some opportunities both for external tools (e.g. a TUI) and CLI users.

1. Templates in shpool list --json

$ shpool list --json
{
  "sessions": [
    { "name": "myproj-edit", "template": "{workspace}-edit", ... },
    { "name": "htop",        "template": null,               ... },
    ...   
  ]
}

An external tool could then use shpool var list to get the current mapping and build the set of each variable's currently-known possible values (by cross-referencing shpool list --json) for easy switching and previewing (a user selects another value for a variable and you show them which sessions would be switched).

You could also include the --dir/--cmd/--start-cmd launch flags in the JSON, which the external tool could use to preview how variable changes would affect runs with templated launch flags.

2. Recipes in config file; per-directory config override files

@ethanpailes floated putting template names in the config file in #341. Since the --dir/--cmd/--start-cmd launch flags also support templates now, you could include them as well, so (template + launch flags) "recipes" could be stored in the config file:

[recipe.edit]
template    = "{workspace}-edit"
dir         = "~/src/{workspace}"
startup_cmd = "{editor}"

[recipe.term]
template    = "{workspace}-term"
dir         = "~/src/{workspace}"

[recipe.agent]
template    = "agent-{workspace}"
cmd         = "ollama run {model}"

CLI users could then shpool attach --recipe edit, and an external tool could surface this from the config, preloading the variable value options, spinning up configured recipes, etc.

3. Named variable presets

This one isn't as pressing for my TUI use case, but might be nice for various workflows.

default_preset = "work"

[var_default]
workspace = "myproj"

# personal preset with preferred editor/language
[preset.work]
editor   = "ed"
language = "taq"
model    = "gpt2"

# preset when showing screen to others
[preset.share]
editor   = "vim"
language = "en"
model    = "claude"

[ethanpailes]

Templates are an attribute of the attach process, not the session. It would of course be possible to send the current template associated with a particular session, but I feel like that impedance mismatch is going to be a footgun that causes a lot of problems.

I can see why someone might want recipies, but I'm also not really clear on what recipies buy users that they can't get with wrapper scripts or aliases. I know it makes the data easier to slurp for wrapper TUIs, but I think shpool features should stand on their own and I like following the principle of there being one way to do things.

I think (3) is already done in #370. I'm not sure how much sense different presets for different styles makes. The var defaults are basically only set when a daemon starts up and after that have no effect, since variables are set at the command line.

[GeoffChurch]

Re (1), I mistakenly conflated sessions and attachments. Would the following make sense / be worth adding?

$ shpool list --json
{
  "sessions": [
    { "name": "myproj-edit", "status": "Attached",     "attachments": [ { "template": "{workspace}-edit" } ], ... },
    { "name": "myproj-term", "status": "Disconnected", "attachments": [], ... },
    { "name": "htop",        "status": "Attached",     "attachments": [ { "template": "htop" } ], ... }
  ]
}

So each session would have a list of attachments, which are objects with a "template" that doesn't necessarily have any vars, per the current impl.

---

Re (2), forgoing recipes makes sense - it doesn't add anything that can't be done in another way. The only benefit would be consolidation of more of the day-to-day workflow into the existing shpool config file.

---

Re (3), what I meant was adding the ability to bundle multiple variable settings under a single name. But, like recipes, it also doesn't add anything new since you could externally maintain presets and apply them with shpool var set sequences, unless you wanted to be able to set all N variables atomically.

[ethanpailes]

Well right now a session can only have zero or one attachment, though there is a FR to allow multiple clients for a single session, so maybe that will change in the future so maybe a list does make sense. I think it would be reasonable to include a list of attached process metadata. We might want to include the attached process pid in the attachment object as well (then a wrapper application could implement a close button for the attach proc if it wanted).

WRT (3) I guess I still don't understand the intended semantics. Variable defaults are only read on daemon boot time, so any preset mechanism would need some way of determining which named groups of bindings are activated, and at that point you might as well put them all in a single default list at the top level. I suppose presets blocks might allow you to switch more quickly. Are you intended to trigger an entire preset block at runtime? If that's the idea then I definitely think that belongs in a helper script or something, not as a native feature of shpool. If it's intended to be switchable in the config, then it seems like that is what toml comments are for. Maybe I'm just missing what the idea is though?

[GeoffChurch]

Yes, I meant "trigger an entire preset block at runtime", and yeah helper script suffices. And I guess even the atomicity feature would be more elegantly+generally handled by extending shpool var set to accept a set of bindings, so that you could have atomicity w/o needing to set up a preset in your config file (but I don't have a need for atomicity anyway).

Including attach proc pid is a good idea.

If everything sounds good, I can start a PR for adding the attachment data (template string + attach proc pid) to shpool list --json.

Is "pid" is sufficiently unambiguous as a field name? E.g. "attachments": [ { "template": "{workspace}-edit", "pid": 1234 } ]. Or would it need to be "attach_pid" or "attach_proc_pid" to disambiguate from the shell pid?

[ethanpailes]

Yeah that sounds good to me, go for it. I think just "pid" is fine since it is already in the attachements list so it should be clear positionally, but if you want to make it longer I would be fine with that too.

[GeoffChurch]

PR is #379

[ethanpailes]

Thanks! I just left a few comments, looks pretty good.