-
Notifications
You must be signed in to change notification settings - Fork 298
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Named groups of tasks #81
Comments
Hmm, interesting idea. Can it be easily implemented in a clean way? |
I am also interested in this feature! Just started using Even an entry like |
I really want to work on this! I had a slightly different idea, though: using an # 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 :) |
|
Great! I'm on it! |
I like it. It would also make system-dependent configs cleaner (rather than depending on |
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 ./install --except '@fish' What do you think? P.S. If you think it's acceptable, I can create a PR. |
I have similar thoughts as expressed in #225 (comment) and #35 (comment). 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 #35 (comment) soon.) |
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. |
Howdy. I've been working on something similar/overlapping with this issue over in #225 and #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 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? |
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:
While this works great, it leads to the output of dotbot not being as easy to parse:
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:
(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.)The text was updated successfully, but these errors were encountered: