Live data from Hacker News

Rotz: Cross platform dotfile manager written in Rust

volllly.github.io

21–30 of 46 posts

Re: Rotz: Cross platform dotfile manager written in Rust

#23

I don't get those dotfile managers. I just have a git repo with a branch for every machine. And my dotfiles are in many formats, not just yaml toml and JSON...

> I just have a git repo with a branch for every machine.

Aren't you supposed to "not" commit secrets/sensitive values to git repos as "best practice"?

Re: Rotz: Cross platform dotfile manager written in Rust

#24
post #12
post #10

Reminds me of my own project, Comtrya One of our goals is to run anywhere too, we have support for BSD as well as Windows, macOS, and Linux; as well as first class variant support for "define once, run everywhere" functionality. Our core lib is available and built to support other dot file managers, perhaps it could be useful to you. https://github.com/comtrya/comtrya

I'm yet to look at your project, but I can't say Comtrya without thinking about Stargate, so I'm kinda sold already.

"This is...better?" :-)

Re: Rotz: Cross platform dotfile manager written in Rust

#25

I don't get those dotfile managers. I just have a git repo with a branch for every machine. And my dotfiles are in many formats, not just yaml toml and JSON...

> I just have a git repo with a branch for every machine. Aren't you supposed to "not" commit secrets/sensitive values to git repos as "best practice"?

I guess it's a private repo...

Re: Rotz: Cross platform dotfile manager written in Rust

#26

I don't get those dotfile managers. I just have a git repo with a branch for every machine. And my dotfiles are in many formats, not just yaml toml and JSON...

I also don't get these, but for another reason: why write a dotfiles-specific configuration management tool with templating, conditions and all of that when we already have proper SCMs like salt or ansible that perfectly scale down to a single user and a small number of configs, but are still orders of magnitude more powerful when you need it.

Re: Rotz: Cross platform dotfile manager written in Rust

#28
Hm, I don't think I understand how this is supposed to work. The documentation is very barebones and doesn't explain much.

It talks about symlinking your dotfiles from somewhere else on your system, so is this only useful if you have multiple users and they share dotfiles? How does that help if you want to sync dotfiles between machines?

Then it talks about YAML and toml formats but it's not very clear to me if that is the format of the dotfiles that it manages, or if that is only the config file for Rotz itself?

Also it looks like you have to write a config file for every dot file you manage?

This seems overly complicated to, say, a simple git repo. A simple example would have been helpful in the documentation I guess....

Re: Rotz: Cross platform dotfile manager written in Rust

#29
post #26

I don't get those dotfile managers. I just have a git repo with a branch for every machine. And my dotfiles are in many formats, not just yaml toml and JSON...

I also don't get these, but for another reason: why write a dotfiles-specific configuration management tool with templating, conditions and all of that when we already have proper SCMs like salt or ansible that perfectly scale down to a single user and a small number of configs, but are still orders of magnitude more powerful when you need it.

I will do a lot of work to avoid having to touch ansible and friends. Fortunately, I don't have to do a lot of work because I spent 10 minutes writing a 50 line Go program a decade ago that has done everything I've needed it to do in the interim (IIRC the only change I made to it was supporting Go modules back in ~2015).

Re: Rotz: Cross platform dotfile manager written in Rust

#30

I don't get those dotfile managers. I just have a git repo with a branch for every machine. And my dotfiles are in many formats, not just yaml toml and JSON...

> I just have a git repo with a branch for every machine. Aren't you supposed to "not" commit secrets/sensitive values to git repos as "best practice"?

Perhaps SSH/GPG private keys are .gitignored?
Post reply on HN