Simplify/unify the config format of workspaces and repositories

[savq]

Hi,

I've been using tab for a good while now, and I find it really useful. Recently however, I realised I haven't really been using the workspaces feature at all, and reading the related docs left me with some doubts (maybe it's just a matter of nomenclature), so I thought I'd ask before suggesting any changes.

When defining a workspace, it'll be available to the subdirectories of the directory where it was defined, however, the examples include child workspaces and a similar mechanism for repositories. With that in mind:

• Is there any advantage to having nested tab.ymls instead of adding the relevant metadata to the root/parent workspace?

• What's the advantage of having a separate system for repositories? Doesn't having a tab.yml in the root of the repo work the same?

• Is there any reason tab uses tab.yml instead of a hidden .tab.yml?

Once again, thank you for all the work you've put into this project!

[austinjones]

Hey @savq,

Workspaces help when you have a ton of tab configurations, and you want to keep tabs visible within the workspace directory. Maybe the best way to explain this is an example of how I use it. Here is my ~/open-source/tab.yml workspace config:

doc: "open source repositories"

workspace:
  - repo: lifeline-rs
  - repo: tab-rs
  - repo: postage-rs
  - repo: tiwi-rs
  - repo: not-exists
  - repo: homebrew-taps
  - repo: this-week-in-rust
  - tab: bash
    shell: bash
  - tab: zsh
    shell: zsh
  - tab: screen
  - tab: tmux
  - tab: any
    doc: "random tasks"

And in ~/.config/tab.yml, I have:

workspace:
  - workspace: open-source
  - workspace: other-repos

tab -l from my home directory is nice and clean:

❯ tab -l
Available tabs:
    austinjones/    (austin's home directory)
    open-source/    (open source repositories)
    other-repos/      (my other repositories at ~/other-repos)

Due to the link in ~/.config/tab.yml, I can always activate the open-source workspace on the command-line or fuzzy finder:

❯ tab open-source/
super-terminal with alacrity, fish, powerline, `tab` multiplexer, and navi/zoxide.  try `help`

tab open-source/  ❯ tab --list
Available tabs:
    any/              (random tasks)
    austinjones/      (austin's home directory)
    bar/
    bash/
    foo/
    homebrew-taps/
    lifeline/         (lifeline-rs, a dependency injection library for async channels)
    open-source/      (open source repositories)
    postage-rs/
    screen/           (screen, the GNU terminal multiplexer)
    tab/              (the tab-rs terminal multiplexer)
    tmux/             (tmux, the next-gen terminal multiplexer)
    twir/             (this week in rust, the weekly rust newsletter)
    workspace/        (threatx repositories)
    zsh/

Repo configs are nice if you need a lot of tabs for a particular project. project/git, project/run-frontend, project/run-backend, project/logs, etc. And if you need to share config (shells/env), that can be configured for all the project tabs in one place. Without a workspace, you'd have to cd into the project to get those tabs. But workspaces 'pin' the tabs, even in sibling directories.

You can definitely define all your tabs at the workspace level, or even at ~/.config/tab.yml. But child repo configs save repeated relative paths, and they are accessible in code editors when you have a project open.

I don't have a great use case for workspaces within workspaces - maybe someone with a lot more tabs than I do will find a use :D The support for nested workspaces is how ~/.config/tab.yml works with ~/open-source though, so when I implemented that for the global config, I added a bit of documentation (because it does work).

Oh, and tab actually supports .tab.yml for local config files. The global config would require setting $TAB_CONFIG though.

[austinjones]

Also, thanks so much for using tab! If you have any thoughts on how to make the config easier to use, I'd be really interested :)

[jeizsm]

I recently found tab-rs and had this exact question. I think the difference between repos and workspaces rather unclear. Why don't have only repos that can include other repos like that? ~/.config/tab.yml

repo:
  - repo: open-source
  - repo: other-repos

~/open-source/tab.yml

repo:
  - repo: tab-rs
  - tab: bash
    shell: bash

❯ tab -l
Available tabs:
    austinjones/
    austinjones/open-source/
    austinjones/open-source/tab-rs 
    austinjones/open-source/bash
    austinjones/other-repos/

[austinjones]

Interesting. I'll rethink this and see if there is a way to unify the config formats.

[savq]

Hey @austinjones,

Your example does clear some things up, but @jeizsm comment makes me think this is a common source of confusion.

With that in mind, my first intution/draft proposal for a different config system would be:

• 1 tab.yml corresponds to 1 workspace
• workspace == repo == bundle of tabs + docstring + env. variables
  • (remove the distinction between workspaces and repos)
• tab = session + docstring + env. variables
• tabs inherit env. variables from their workspace (unless overwritten)
• links are allowed, but should be named link rather than workspace
• workspaces can't overwrite their names (to make linking consistent)

The big difference is that workspaces would be abstract, i.e. any tab instace in the workspace has to be explicit (no default tab), which might not be how other people understand the idea of a workspace. So obviously it's not the best alternative right now.

Since this is mostly a design decision, rather than an implementation problem, I think that pinning it and letting other folks give their opinion would be really useful.

[austinjones]

Hey @savq, I like it. I'm going to think about it a bit more. And if anyone has thoughts, please chime in :)

[austinjones]

I found a way to make this change in a backwards-compatible way. I'm thinking of including this in v0.6.0, and deprecating the old format in v0.7.0.