Live data from Hacker News

Migrating from GNU Stow to Chezmoi

rednafi.com

111–120 of 152 posts

Re: Migrating from GNU Stow to Chezmoi

#111
post #106

Earlier quoted context omitted.

If you modify a base package, like maybe to apply some minor patch on a systemd executable as an example, is there a way to avoid having to recompile basically all installed packages (for being at least indirect dependents)? Had a problem like that about a decade back.

No, it doesn't recompile everything, that's not how Nix works. The only way it would recompile everything is if, for example, you modified a particular version of glibc that was imported by most packages. Something else must have happened. I modify udev rules and the system rebuilds in seconds. That's the great thing about nix, it should actually compile LESS than other distros, because, you can have multiple version…

> The only way it would recompile everything is if, for example, you modified a particular version of glibc that was imported by most packages.

The package dependencies aren't based on whether what's packaged is a linked library, and built packages are linked to the dependencies by the digests. The digest of a package is made from the store derivation which contains the digests of the dependencies. Or does the digest of a package not depend on the digests of its dependencies anymore?

Because if they do, then on changing any minor thing, like a typo on a manpage, it would cause the change to cascade by changing the digests of its own package and its dependants recursively. Meaning, none would be found prebuilt and would need to be recompiled.

EDIT: s/hashes/digests/ because that's what appears to be the conventional name for the base32 strings used to identify an entry in /nix/store. The site has changed a lot in the last decade, but I do see this in the thesis that confirms what I remembered:

> The store derivation in /nix/store/1ja1w63wbk5q...-hello-2.1.1.drv is shown in Figure 2.13. It lists all information necessary to build the component, with references to the store derivations of dependencies [...] The output field specifies the path that will be built by this derivation, if and when it is built. It is computed essentially by hashing the store derivation with the output field cleared. --- https://edolstra.github.io/pubs/phd-thesis.pdf

EDIT 2:

> I modify udev rules and the system rebuilds in seconds.

Maybe there's a beaten path for udev rules, a way to override them without modifying the package / store derivation. Or maybe the derivations you're modifying don't have many dependants.

Re: Migrating from GNU Stow to Chezmoi

#112
post #69

Earlier quoted context omitted.

Git works until you need conditional logic such as platform-specific files or templating.

There are various options: You can make forks or branches. Perfect for separating your work specific or private configs You can use a filter like https://github.com/darkfeline/qualia-go You can use a shell script (stored in the same git repo). You need you run an external tool with dotfile managers anyway, a shell script gives you more flexibility and doesn't need an extra dependency which might break at an inopportu…

You can, but forks or branches need constant merging or rebasing (and sometimes conflict resolution) for each one. Clean/smudge filters are fiddly to set up correctly and almost certainly require shelling out to another program, which could break. The second-to-last thing you need is your hand-rolled solution breaking on a new environment. If and when you need several advanced features that a stable dotfiles manager already covers, why roll your own?

Re: Migrating from GNU Stow to Chezmoi

#113

> 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 find this is a key feature. If a file is edited, git shows it as dirty, and I get to decide if I discard of commit the change. No extra steps required. > By the time Homebrew and a couple of tools have run on a new Mac, files like ~/.zprofile and ~/.gitconfig already exis…

The issue is that you don't really see the git dirty/clean status, because you are rarely/never inside the actual git working tree on your machine. I manage my dotfiles with a simple script that symlinks, and when I go and edit one of those files (through the symlink), I'm either editing from my homedir, or from the directory containing the symlink. When the edit is done, I don't see any git status, because I'm not inside the git repo working tree.

I end up with the same issue as OP: months and months later I'll pop into ~/.dotfiles (where I keep the git repo), and see the tree is dirty, with all these random changes I've made that I don't really remember all that well.

The difference for me vs. the OP is that I consider it a minor inconvenience, spend a few minutes cleaning up and committing, and go about my day. It also helps that I'm pretty much a single-machine guy. I have the dotfiles on random server-like machines in my house, but I basically never edit them on those machines; all edits happen on my laptop, so I never have a problem with conflicts. I could definitely see how this could get annoying for people who edit their dotfiles on several different machines.

Re: Migrating from GNU Stow to Chezmoi

#115
post #18

Once you hit the Chezmoi stage, you're only about 6 months from Nix and Home Manager. I mean, why climb _almost_ to the top of a mountain and then just sit down?

I've bounced off Nix every time I tried it, before I even started trying something like Home Manager. I've been using (and contributing to) chezmoi for ~6 years now. Given that it has first-class integration with secrets managers, I suspect that it does things that Home Manager can't.

> it has first-class integration with secrets managers

Meow?

Re: Migrating from GNU Stow to Chezmoi

#116
post #8

I’ve always managed this problem in a different way. I don’t know if my way is better, but it works really well for me. I treat my powerful desktop computer as my main machine. Then I have a bunch of laptops. Then I just rsync my entire home directory out to all the laptops. From there. The rule is quite simple. Any file created on a laptop are considered ephemeral. If I create data that I have to keep. It gets rsync…

I feel like git or other vcs would be a bit safer. I could see myself syncing the wrong way.

Re: Migrating from GNU Stow to Chezmoi

#117
post #69

I've never really understood why people get so fancy with their setups when you can just plop a git repo into your home directory. I suspect it has to do with people being unfamiliar with git.

Git works until you need conditional logic such as platform-specific files or templating.

I'm multi-platform and use git. A few scripts include things like this, but for the most part are portable.

    # fish
    if set -q TERM_PROGRAM  # mac os
       ...
    else if test "$COLORTERM" = "kmscon"
        ...
    else  # tron leotards
        ...
    end

    # bash
    if test "$WAYLAND_DISPLAY" == ""; then  
        echo X11
    else
        echo Found Wayland
    fi

    if test -e /etc/fedora-release; then
        echo ...
    else
        # Debian
    fi

Re: Migrating from GNU Stow to Chezmoi

#119
post #113

> 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 find this is a key feature. If a file is edited, git shows it as dirty, and I get to decide if I discard of commit the change. No extra steps required. > By the time Homebrew and a couple of tools have run on a new Mac, files like ~/.zprofile and ~/.gitconfig already exis…

The issue is that you don't really see the git dirty/clean status, because you are rarely/never inside the actual git working tree on your machine. I manage my dotfiles with a simple script that symlinks, and when I go and edit one of those files (through the symlink), I'm either editing from my homedir, or from the directory containing the symlink. When the edit is done, I don't see any git status, because I'm not i…

For this, I just added a section to my prompt (bash) showing the state of my dotfiles repo (using yadm). This made sense to me because I'd already done this for a git repo in my current dir. I originally rolled my own but eventually found https://github.com/romkatv/gitstatus which is much faster. So, along with background fetches/pushes, at any point I can tell what revision my dotfiles repo is on and whether it's clean, up to date, conflicted, etc. The time cost for my whole prompt is <20ms.

Re: Migrating from GNU Stow to Chezmoi

#120
post #6

I've been using [yadm]( https://yadm.io/ ) instead which works really well!

I've been happy with yadm for few years now. I had tried chezmoi, but preferred yadm. I don't remember my exact reasons though...

I looked around at a bunch but settled on yadm for basically just using a normal git workflow. I wanted to just edit the files directly, know what it's doing, and not change how I worked. I really dislike the ` edit/run/` UI pattern that's fairly common now.
Post reply on HN