Live data from Hacker News

Migrating from GNU Stow to Chezmoi

rednafi.com

81–90 of 152 posts

Re: Migrating from GNU Stow to Chezmoi

#82
> The trouble is that symlinks cut both ways. Every edit on every machine writes straight through the link into that machine’s clone of the repo

I have stow too in my micro DE, use it across a few machines and it's holding up really well. I designed my dotfiles so that changes would happens exclusively to files not tracked by stow. I have .zshrc tracked, but environment goes to .zshenv and general local customisation goes to .local/lib/zsh/overrides.zsh (https://gitlab.com/gabriel.chamon/archie/-/blob/main/deploym...). Hyprland config is tracked but device specific configs live in .config/hype/config/device.conf (https://gitlab.com/gabriel.chamon/archie/-/blob/main/deploym...). Deployment instructions/automation is to just copy dist folders in place, which aren't tracked by stow.

It depends on everyone's style. For me personally changes I don't remember having made to files I track in the repo are symptoms that I might need to review how I organize my files. Maybe those changes were something that broke and I forgot to commit after fixing. In any case for me this bidirectional nature of symlinks are a feature, not a bug in this management system.

Re: Migrating from GNU Stow to Chezmoi

#83
post #58

Earlier quoted context omitted.

Its the only complete, reproducible, and portable solution, in my opinion. I like mise, but at the end of the day some programs are more complex than just pulling a precompiled, dynamically linked binary and hoping it works.

I am genuinely confused. Are you saying dotfile managers need to be more complex? Or that nix's problem space is the only solution for the things in nix's domain? (of which dotfiles are just one—via home manager) I thought it was the former but "just pulling a precompiled, dynamically linked binary and hoping it works" makes me think we're not on the same page since to me that has nothing to do with dotfiles.

I don't think you're genuinely confused.

Are you really in this thread to talk about dotfile managers, or are you here to criticize Nix, given that Nix directly competes with your company's only product?

Re: Migrating from GNU Stow to Chezmoi

#84

Earlier quoted context omitted.

Last time I looked, it only worked with NixOS. I don't understand what makes it more understandable than Home Manager, though. If you look at the source of a Home Manager `programs.foo` module, it should look mostly like this: home.packages = [ cfg.package ]; xdg.configFile."foo/config.yaml".source = yamlFormat.generate "config.yaml" cfg.settings; Which is pretty much exactly the same syntax you get with Hjem, but wi…

It works on darwin and any linux just fine. Theyre even working on a "standalone" like HMs, if you really want to decouple your user programs from your system. With some programs it is as simple as you show, but with others there are options around the config and other nix module nasties that I avoid if I can. hjem-rum is a sister project to hjem that provides some similar modules.

I'll take a look again once it's a bit more mature. I need a standalone, single-user, rootless mode for it to work on all my systems.

Thanks for the recommendation.

Re: Migrating from GNU Stow to Chezmoi

#86
post #58

Earlier quoted context omitted.

I am genuinely confused. Are you saying dotfile managers need to be more complex? Or that nix's problem space is the only solution for the things in nix's domain? (of which dotfiles are just one—via home manager) I thought it was the former but "just pulling a precompiled, dynamically linked binary and hoping it works" makes me think we're not on the same page since to me that has nothing to do with dotfiles.

I don't think you're genuinely confused. Are you really in this thread to talk about dotfile managers, or are you here to criticize Nix, given that Nix directly competes with your company's only product?

Considering nothing in that reply criticized nix you’re certainly wrong. I don’t hesitate to share my opinions on nix anytime (just like nix users themselves) so I’d have no reason to be coy about my criticism.

tfrancisl was polite (even though I arguably wasn’t in the beginning) so I felt it important to return the favor.

Re: Migrating from GNU Stow to Chezmoi

#87
post #74

Earlier quoted context omitted.

I'm saying that I value the completeness (thoroughness may be a better word) as well as the reproducability and portability that nix ensures over convenience. I cant tell you the amount of times I've pulled a precompiled tool and it just doesnt work because of one quirk of their packaging or another. Also noting that I don't see the problem as "dotfile management" but as "system AND user configuration management" whi…

> I can't tell you the amount of times I've pulled a precompiled tool and it just doesnt work because of one quirk of their packaging or another. This is a serious problem in Nix too. I often trip over buggy and abandoned Nix packages. Nix often makes it easy to roll back or work around them, but they're absolutely there.

They still build though. No one said anything about Nix being a solution to buggy software or bad maintainers, that's an absurd expectation.

Re: Migrating from GNU Stow to Chezmoi

#88

Chezmoi strikes a nice balance between the overkill of home-manager while still being more powerful than simpler solutions. Yadm is another alternative, the main thing I don't like about it though is that I'm not a fan of cross OS dotfiles. Having niri files on my work Mac and aerospace dotfiles on Linux annoys me quite a bit. As powerful as the templating in chezmoi is, I think it should be considered a last resort…

  > Having niri files on my work Mac and aerospace dotfiles on Linux annoys me quite a bit
https://www.chezmoi.io/reference/special-files/chezmoiignore...

  > They break your editor features like highlighting
https://github.com/alker0/chezmoi.vim

Re: Migrating from GNU Stow to Chezmoi

#89

i feel like using GNU stow to manage your dotfiles has always been a hack.. has it ever been a supported usecase? stow is an indispensable tool for me to manage /usr/local for manually installed software. my workflow goes: ./configure --prefix=/usr/local/stow/myapp make && make install stow myapp now, myapp and all its supporting files are in the right place in /usr/local. if i want to "uninstall", i just run stow -D…

I like to use environment modules [1] (or lmod [2]) for that purpose. You can make each manually built software package available or not on a per-shell-session basis, just by running

    module load myapp
or

    module unload myapp
in the shell where you want it (or don't). The small downside is that it only works with software that actually uses the standard environment variables like PATH, CPATH, etc. for their intended purposes rather than hardcoding filesystem paths, but in my experience it's rare to find something that doesn't. Also, you have to write a modulefile for each package, but that's not a big deal.

[1]: https://modules.readthedocs.io/en/latest/ [2]: https://lmod.readthedocs.io/en/latest/

Post reply on HN