Named groups of tasks

[kazmasaurus]

Something I'm currently doing is grouping related commands by their goal rather than their type, i.e. instead of having all the links together, I have:

#### vim ####
- shell:
    - [git submodule update --init --recursive "vim/vim-plug", Installing vim-plug]
- link:
    ~/.vimrc: vim/.vimrc
    ~/.vim/autoload/plug.vim: vim/vim-plug/plug.vim

### fish ###
- link:
    ~/.config/fish/config.fish: fish/config.fish

While this works great, it leads to the output of dotbot not being as easy to parse:

• It's pretty hard to see where one goal ends and the next begins, even with the green success messages.
• The success messages aren't a great fit for repetition, it's a little weird to see "All commands have been executed" multiple times.

Given this, it would be cool to lift this sort of jobs pattern into dotbot itself, so that dotbot can intelligently group output based on the jobs. I'm thinking something like this:

- jobs:
    vim: 
        - shell:
            - [git submodule update --init --recursive "vim/vim-plug", Installing vim-plug]
        - link:
            ~/.vimrc: vim/.vimrc
            ~/.vim/autoload/plug.vim: vim/vim-plug/plug.vim
    fish:
        - link:
            ~/.config/fish/config.fish: fish/config.fish

(I'm not particularly for or against the top level jobs task, but it seems like the easiest way to fit into the current plugin capability.)

[anishathalye]

Hmm, interesting idea. Can it be easily implemented in a clean way?

[clintval]

I am also interested in this feature! Just started using dotbot last week and love it. Definitely replicates what I have been hand-scripting for months.

Even an entry like label which would render a horizontal labeled rule with another color would help me distinguish groupings of tasks. Over holiday here I'll see if I can sketch out a prototype.

[ghalestrilo]

I really want to work on this! I had a slightly different idea, though: using an include keyword, which calls dotbot on other files. This would allow for setup reuse, and the implementation is really straightforward.

# main.conf.yaml
- include:
  - ./vim.conf.yaml
  - ./fish.conf.yaml

# vim.conf.yaml: 
- shell:
  - [git submodule update --init --recursive "vim/vim-plug", Installing vim-plug]
- link:
  ~/.vimrc: vim/.vimrc
  ~/.vim/autoload/plug.vim: vim/vim-plug/plug.vim

# fish.config.yaml: 
- link:
  ~/.config/fish/config.fish: fish/config.fish

As of right now, I'm kind of hacking around to achieve that same effect - having this as an out-of-the-box feature would be very helpful managing a multi-computer setup, such as mine. If you guys think it's worth it, I'll fork the repo and start working on it :)

[anishathalye]

include seems like a nice feature to have. If you want to start working on it, I'm happy to provide feedback on PRs and stuff. Let me know if you have any questions 😄

[ghalestrilo]

Great! I'm on it!

[Bao-gxg]

I like it. It would also make system-dependent configs cleaner (rather than depending on link: if: as I currently do, via #173)

[schmidtandreas]

To group the tasks is a great idea. I have the following suggestion to keep the implementation simple:

- link@fish:
  ~/.config/fish/config.fish: fish/config.fish
 
- shell@fish:
  - [git submodule update --init --recursive "vim/vim-plug", Installing vim-plug]

- link@vim:
  ~/.vimrc: vim/.vimrc
  ~/.vim/autoload/plug.vim: vim/vim-plug/plug.vim

The dispatcher only has to cut off the group after the @ sign. It is also backward compatible.

In addition, the functionality of arguments only and except could be extended to handle only a certain group:

./install --except '@fish'

What do you think?

P.S. If you think it's acceptable, I can create a PR.

[anishathalye]

I have similar thoughts as expressed in https://github.com/anishathalye/dotbot/issues/225#issuecomment-653208889 and https://github.com/anishathalye/dotbot/issues/35#issuecomment-171951443. tl;dr I don't really want the YAML config file to slowly grow into a programming language embedded in YAML (e.g. like Ansible). If we really do need those generic programming language constructs like conditionals, perhaps a better solution is to create a DSL embedded in a real programming language (Python, or maybe something else). It's a tricky design decision to figure out exactly what features to include in our YAML config file. I want to spend a bit more time thinking about that before complicating the semantics of the YAML config any further. Would love to hear your thoughts on this. (I've been a bit busy recently; I hope to have a slightly more concrete proposal than the hypothetical examples in https://github.com/anishathalye/dotbot/issues/35#issuecomment-171951443 soon.)

[schmidtandreas]

I agree with you, it is blade-running between the conditional installation of the dotfiles and transforming the yaml-config-file into its own programming language. I did not consider this point in my considerations.

However, the problem of conditionally handling each entry is still there. Taking into account your comment, the solution proposed by kazmasaurus would be the better solution, something like:

groups:
  vim: 
    - shell:
        - [git submodule update --init --recursive "vim/vim-plug", Installing vim-plug]
    - link:
        ~/.vimrc: vim/.vimrc
        ~/.vim/autoload/plug.vim: vim/vim-plug/plug.vim
  fish:
    - link:
        ~/.config/fish/config.fish: fish/config.fish

I think I could try to implement it in clean way.

[davesteinberg]

Howdy. I've been working on something similar/overlapping with this issue over in https://github.com/anishathalye/dotbot/issues/225 and https://github.com/anishathalye/dotbot/pull/229

Since a task is already a dictionary of actions, my idea was to use tasks as the unit of composition, rather than needing to add groups above them. My PR allows you to include a task property to specify a name and (optionally) an if property to specify an applicability test. If you do this, then you need to nest the actions under an actions property. Or, you can use anonymous tasks that don't do any logging, just like before.

I just pushed the second revision of my PR, and I haven't gotten any feedback from @anishathalye yet, but I'm also interested to hear if my idea meets the needs expressed in this issue. What do folks think?