I’m planning on moving my website from its French server to one in the Netherlands (I use Scaleway and read during the week that their NL instances were lower latency). I’d also like to get a blog post about Thea’s performance written.
I like GNU stow. A lot. One of the things I like about it is that if I edit the config file using whatever the usual mechanism is for the app, it shows up in my dotfiles repo as a change that needs to be resolved. I don’t think that would happen (organically) with a copy based system.
The one thing I wish GNU stow could do is merge different sources of truth for a single target. By that I mean, I might want to keep most of my config data in a single repo for all my systems, and have a second repo that’s machine-specific that gets merged in somehow.
Does jann have an answer for either of these? i.e. if I edit ~/.config/kitty/kitty.conf using my text editor, will jann detect that and show me that I need to sync it to my dotfiles repo? And does it offer some way to have system-specific mods to my main dotfiles?
(I hope neither question sounds pointed… they are absolutely not meant that way… the right answer to the second one might make me want to switch if the answer to the first is livable.)
I built my own tool to solve these problems as well – https://github.com/dcreemer/wsup ; it uses the concept of layers – I add my generic personal dotfiles on most hosts, then add in a couple layers for machine or project specific configs. All files are symlinked back to the layer git repo.
This is a nice project. Forgive me if I’m not reading this right, but am I right in saying that as it the directory structure of the dotfile repo(s) needs to match the structure of your home directory? I must admit that was one of the reasons I disliked GNU Stow.
Yes, you are correct. I wanted each “layer” to be a mirror of the home directory structure for ease of understanding. In this way, my “personal-private” layer can include files from ~/.ssh/ as can my “work1-private” layer. They both integrate into the “real” ~/.ssh/ directory.
The one thing I wish GNU stow could do is merge different sources of truth for a single target. By that I mean, I might want to keep most of my config data in a single repo for all my systems, and have a second repo that’s machine-specific that gets merged in somehow.
yadm offers machine-specific files. It doesn’t provide a templating or inclusion system, but I don’t often need one.
if I edit ~/.config/kitty/kitty.conf using my text editor, will jann detect that and show me that I need to sync it to my dotfiles repo
jann does not have this feature. That said, some sort of jann --diff might be a really good addition. I must admit, since I edit virtually all the dotfiles that matter to me from a text-editor, I had not considered the case of application-modified files.
And does it offer some way to have system-specific mods to my main dotfiles?
No, but I want it to in the future. I have thought quite a lot about introducing some sort of patch-based system to jann to allow this sort of functionality, but it’s not present at the moment (I would really like any suggestions anyone has on how to do this elegantly!). A lot of applications offer the option to put multiple config files in a /config.d/ directory - so for Sway, I put my machine specific config in there, and just let jann manage the main config. Another more hacky, but workable solution, would be something like the following (note the slightly confusing paths are because jann enters a ./deploy directory when it executes - I may in future pre-populate the symbol table with BUNDLE and DEPLOY global variables to make this sort of scripting more readable).
Edit: I have added the BUNDLE variable. DEPLOY is a little more complicated for technical reasons.
I don’t know much about rust and its ecosystem, so just dismiss me if I’m suggesting something that doesn’t fit the model you’re working with. But I’ve been tempted before to solve the problem using some templating engine. (ecosystem aside, after that, I start to feel like I’m rewriting puppet and slink back into my symlink-laden cave.)
Rust does, from what I understand, have some decent templating libraries. I know there is one that is a rough port of jinja which is rather nice. However, were I to implement templating - which sounds like it could be a worthwhile avenue - I would probably do it myself. Yes, I know that’s NIH syndrome, but it’s something I would enjoy doing and I’d be lying if I said that 40% of the reason for building jann wasn’t just a desire to write another parser :-)
Your comment about Puppet is very amusing to me, because another significant part of the reason why I built jann was being intimidated by Puppet, Ansible, et. al. The prospect of installing a huge program with the website tagline ‘DevOps automation for a multi-cloud world’ to manage a dozen text files on my laptop seemed a textbook case of cracking a nut with a hundred-tonne steam hammer! I am eager to ensure that jann strikes a good balance between covering people’s use-cases and remaining a small, reasonably elegant binary that ‘does one thing well’.
The idea of avoiding “(XYZ overkill thing) to manage a dozen text files on my laptop” resonates. I think I occupy an odd middle zone in what I want from this kind of utility.
Mostly because my dozen config files are used in different ways across the three relatively disposable laptops I have to touch regularly. There’s my “daily driver” thinkpad, my “I need to mod my iOS app on the road” macbook and my “I need to cross a foreign border or go someplace it’ll probably get stolen” 10 year-old thinkpad with almost no personal data on it.
I want slightly different dots for all of these :)
chezmoi has templating for configs that differ between machines; sounds like it might fulfill your requirements. I only started using it recently as a replacement for my manually-managed symlinks but like it so far.
I’m kinda starting to work on Yet Another™ “Dotfiles Manager” (though I want to use it to manage whole machines eventually, kinda poor man’s NixOS-inspired way). A crucial for me feature is that it should detect any changes between previous “deploy” and the current one, clearly show the diffs, and only be able to re-deploy after they’re resolved (it’s going to be copy-based).
I wanted to use CUE as the config language, but it showed up to be somewhat too early-stage for my liking (mainly through poor error messages), so now I intend to use Lua instead (which I know pretty well). You’re welcome to watch the repo if only for releases if you like, though usual disclaimer that I don’t promise any kind of a timeline/ETA.
I’m planning on moving my website from its French server to one in the Netherlands (I use Scaleway and read during the week that their NL instances were lower latency). I’d also like to get a blog post about Thea’s performance written.
I like GNU stow. A lot. One of the things I like about it is that if I edit the config file using whatever the usual mechanism is for the app, it shows up in my dotfiles repo as a change that needs to be resolved. I don’t think that would happen (organically) with a copy based system.
The one thing I wish GNU stow could do is merge different sources of truth for a single target. By that I mean, I might want to keep most of my config data in a single repo for all my systems, and have a second repo that’s machine-specific that gets merged in somehow.
Does jann have an answer for either of these? i.e. if I edit ~/.config/kitty/kitty.conf using my text editor, will jann detect that and show me that I need to sync it to my dotfiles repo? And does it offer some way to have system-specific mods to my main dotfiles?
(I hope neither question sounds pointed… they are absolutely not meant that way… the right answer to the second one might make me want to switch if the answer to the first is livable.)
I built my own tool to solve these problems as well – https://github.com/dcreemer/wsup ; it uses the concept of layers – I add my generic personal dotfiles on most hosts, then add in a couple layers for machine or project specific configs. All files are symlinked back to the layer git repo.
This is a nice project. Forgive me if I’m not reading this right, but am I right in saying that as it the directory structure of the dotfile repo(s) needs to match the structure of your home directory? I must admit that was one of the reasons I disliked GNU Stow.
Yes, you are correct. I wanted each “layer” to be a mirror of the home directory structure for ease of understanding. In this way, my “personal-private” layer can include files from
~/.ssh/as can my “work1-private” layer. They both integrate into the “real”~/.ssh/directory.I like that scheme. Nice. Thanks for posting that. I’m tempted to adapt it to sit on top of stow.
I would love that, and be happy to help out.
yadm offers machine-specific files. It doesn’t provide a templating or inclusion system, but I don’t often need one.
that was exactly the motivating factor for https://github.com/dcreemer/wsup .
That looks really interesting. Thanks for the pointer.
Thanks for your interest in the project :-)
janndoes not have this feature. That said, some sort ofjann --diffmight be a really good addition. I must admit, since I edit virtually all the dotfiles that matter to me from a text-editor, I had not considered the case of application-modified files.No, but I want it to in the future. I have thought quite a lot about introducing some sort of patch-based system to
jannto allow this sort of functionality, but it’s not present at the moment (I would really like any suggestions anyone has on how to do this elegantly!). A lot of applications offer the option to put multiple config files in a /config.d/ directory - so for Sway, I put my machine specific config in there, and just letjannmanage the main config. Another more hacky, but workable solution, would be something like the following (note the slightly confusing paths are becausejannenters a./deploydirectory when it executes - I may in future pre-populate the symbol table with BUNDLE and DEPLOY global variables to make this sort of scripting more readable).Edit: I have added the BUNDLE variable. DEPLOY is a little more complicated for technical reasons.
I don’t know much about rust and its ecosystem, so just dismiss me if I’m suggesting something that doesn’t fit the model you’re working with. But I’ve been tempted before to solve the problem using some templating engine. (ecosystem aside, after that, I start to feel like I’m rewriting puppet and slink back into my symlink-laden cave.)
Rust does, from what I understand, have some decent templating libraries. I know there is one that is a rough port of
jinjawhich is rather nice. However, were I to implement templating - which sounds like it could be a worthwhile avenue - I would probably do it myself. Yes, I know that’s NIH syndrome, but it’s something I would enjoy doing and I’d be lying if I said that 40% of the reason for buildingjannwasn’t just a desire to write another parser :-)Your comment about Puppet is very amusing to me, because another significant part of the reason why I built
jannwas being intimidated by Puppet, Ansible, et. al. The prospect of installing a huge program with the website tagline ‘DevOps automation for a multi-cloud world’ to manage a dozen text files on my laptop seemed a textbook case of cracking a nut with a hundred-tonne steam hammer! I am eager to ensure thatjannstrikes a good balance between covering people’s use-cases and remaining a small, reasonably elegant binary that ‘does one thing well’.The idea of avoiding “(XYZ overkill thing) to manage a dozen text files on my laptop” resonates. I think I occupy an odd middle zone in what I want from this kind of utility.
Mostly because my dozen config files are used in different ways across the three relatively disposable laptops I have to touch regularly. There’s my “daily driver” thinkpad, my “I need to mod my iOS app on the road” macbook and my “I need to cross a foreign border or go someplace it’ll probably get stolen” 10 year-old thinkpad with almost no personal data on it.
I want slightly different dots for all of these :)
chezmoi has templating for configs that differ between machines; sounds like it might fulfill your requirements. I only started using it recently as a replacement for my manually-managed symlinks but like it so far.
I’m kinda starting to work on Yet Another™ “Dotfiles Manager” (though I want to use it to manage whole machines eventually, kinda poor man’s NixOS-inspired way). A crucial for me feature is that it should detect any changes between previous “deploy” and the current one, clearly show the diffs, and only be able to re-deploy after they’re resolved (it’s going to be copy-based).
I wanted to use CUE as the config language, but it showed up to be somewhat too early-stage for my liking (mainly through poor error messages), so now I intend to use Lua instead (which I know pretty well). You’re welcome to watch the repo if only for releases if you like, though usual disclaimer that I don’t promise any kind of a timeline/ETA.