Live data from Hacker News

Migrating from GNU Stow to Chezmoi

rednafi.com

141–150 of 152 posts

Re: Migrating from GNU Stow to Chezmoi

#141
post #28

It’s quite new but I’ve been cooking up some new bootstrapping features with mise which people may find relevant here: https://mise.jdx.dev/bootstrap.html It’s for things like dotfiles, apt/brew packages, and LaunchAgents/systemd. EDIT: I feel a little bad having hijacked this, as someone that hears a lot of opinions about devtools I can definitely say chezmoi is a darling of the community and I highly recommend chec…

I was just wondering if I could replace my personal Ansible setup with something simpler and now you dropped this.

Perfect timing, I'm already 80% done with the transition :D

Re: Migrating from GNU Stow to Chezmoi

#142
post #111

Earlier quoted context omitted.

> 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…

I didn't say anything about linked libraries. I was just using glibc as an example. I could have used a man page too.

Was trying to figure out why you said that it wouldn't happen with a systemd executable but it would with glibc. Figured it being a library was the difference you meant. Maybe you just meant that glibc has more dependents.

Re: Migrating from GNU Stow to Chezmoi

#143

Earlier quoted context omitted.

Also encryption with `age`. My ssh config has actual domain names of servers I don't want to publish to the whole internet so that file is encrypted on my public github dotfiles repo. Chezmoi automatically decrypts it on `chezmoi update` and I don't need to think about it much unless I'm editing it.

Oh, that's slick. I haven't needed to do that yet and I keep my stuff in a private repo, but see the benefits to it.

I feel that "building in public" works - even for my dotfiles. And it forces me to properly consider what data is public and what isn't from the start.

Re: Migrating from GNU Stow to Chezmoi

#144
post #142

Earlier quoted context omitted.

I didn't say anything about linked libraries. I was just using glibc as an example. I could have used a man page too.

Was trying to figure out why you said that it wouldn't happen with a systemd executable but it would with glibc. Figured it being a library was the difference you meant. Maybe you just meant that glibc has more dependents.

The systemd issue in particular is something I've experienced. nixpkgs does not split systemd into many packages, so everything that needs udev, libsystemd, etc depends on it, so replacing systemd via an overlay will cause a mass rebuild. The trick is to patch systemd and refer to your patched version separately, e.g. with a pkgs.writeShellScript that calls ${systemd-patched}/bin/patched-binary.

Re: Migrating from GNU Stow to Chezmoi

#145
post #130

Earlier quoted context omitted.

If you decide to create a package for the project in nixpkgs, patch-shebangs.sh should do it for you, no?

Getting a patch into `nixpkgs` is not a reasonable bar for running some program you want to try. This is an (admittedly polite) way of saying more or less "you're holding it wrong". I respectfully disagree. For expert users, creating a flake and/or standalone derivation is a little more reasonable of an ask. It is an unreasonable ask of people who are considering adopting Nix, and the friction is artificial, it serve…

You don't have to get a patch into nixpkgs, just use their machinery.

Re: Migrating from GNU Stow to Chezmoi

#147

Earlier quoted context omitted.

> You can just silently use it and enjoy the convenience for the declarative parts of your setup, with no detriment to your ability to run the imperative, ad-hoc setup scripts that your company requires. That's the kicker though. Nix's benefits come from the guarantees it can make based on its integration with the rest of the Nix-controlled ecosystem. Without the control, you don't get the guarantees, and you lose th…

If you’re using Nix and HM to manage a configuration file for a package that isn’t managed by Nix and HM, you don’t get the same guarantees, sure. But you also don’t get them at all with Chezmoi, right? Surely having these guarantees for some packages beats having it for none? In practice _most_ packages you’ll want to use are already in Nixpkgs, and kept up to date. > You need to actively avoid the "value-added" par…

> Surely having these guarantees for some packages beats having it for none? > You can just define that option in your own configuration

This is exactly what I'm talking about. Once you have Nix on your system, it infects everything. You want to let it control everything, because that is where its power is. Your life would be so much easier if you could let it control even more, like the stuff you share with your team. It's the siren call. And then you find yourself pitching it to your team, and then you inevitably fail to pitch it, because you ramped up to it over months and it's just impossible to get anybody else ramped up to Nix that quickly.

It's guaranteed heartbreak every time and I got sick of it.

Re: Migrating from GNU Stow to Chezmoi

#148
post #142

Earlier quoted context omitted.

Was trying to figure out why you said that it wouldn't happen with a systemd executable but it would with glibc. Figured it being a library was the difference you meant. Maybe you just meant that glibc has more dependents.

The systemd issue in particular is something I've experienced. nixpkgs does not split systemd into many packages, so everything that needs udev, libsystemd, etc depends on it, so replacing systemd via an overlay will cause a mass rebuild. The trick is to patch systemd and refer to your patched version separately, e.g. with a pkgs.writeShellScript that calls ${systemd-patched}/bin/patched-binary.

> The trick is to patch systemd and refer to your patched version separately

I mean, generally when you patch things, you want all dependents to use the patched version. It's just irksome that you know the change you made strictly speaking doesn't need a rebuild of dependents, but nix will still require it in the interest of ensuring reproducibility. Just wish there were an established expert-mode I-know-this-may-break-things way to have a modified derivation act as a drop-in replacement of a particular package/digest.

For example, it would be neat to have derivation foo.nix, from which the digest is calculated. Then, have the system check for a mod/foo.nix or similar path which would be a function that can modify the derivation without having the digest be recalculated on the result. Or maybe this could be done by having a function calcDigest, which sets the digest of a derivation and the system can simply not set the field when it's already been set. This to allow further changes while being treated as if changes haven't been made.

Re: Migrating from GNU Stow to Chezmoi

#149
post #52

Earlier quoted context omitted.

Ha, I came here to share this! :) Thanks so much for your work on mise! I used to be a heavy asdf user but nowadays I'm an even heavier mise user! Random question while you're here: mise is undergoing pretty heavy development these days and I recently noticed that 1) my coworkers and I are not always on the same version, so some features/bug fixes are not available to everyone, and 2) package registries often don't h…

The problem with mise managing its own version is perf. I don't want a shim that has to read config files to exec the right version. I would make use of min_version. It's not perfect, but will at least help bring laggards along.

That makes sense! I wasn't aware of min_version for some reason, thanks so much!

Re: Migrating from GNU Stow to Chezmoi

#150

Earlier quoted context omitted.

If you’re using Nix and HM to manage a configuration file for a package that isn’t managed by Nix and HM, you don’t get the same guarantees, sure. But you also don’t get them at all with Chezmoi, right? Surely having these guarantees for some packages beats having it for none? In practice _most_ packages you’ll want to use are already in Nixpkgs, and kept up to date. > You need to actively avoid the "value-added" par…

> Surely having these guarantees for some packages beats having it for none? > You can just define that option in your own configuration This is exactly what I'm talking about. Once you have Nix on your system, it infects everything. You want to let it control everything, because that is where its power is. Your life would be so much easier if you could let it control even more , like the stuff you share with your te…

> Your life would be so much easier if you could let it control even more, like the stuff you share with your team. It's the siren call.

You could always, you know, not do this. Your heart will be intact.

Post reply on HN