Migrating from GNU Stow to Chezmoi
121–130 of 152 posts
Re: Migrating from GNU Stow to Chezmoi
#122Earlier quoted context omitted.
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…
Re: Migrating from GNU Stow to Chezmoi
#123Does Chezmoi have a better solution for that? Or is there a better way using Stow?
Re: Migrating from GNU Stow to Chezmoi
#124Earlier quoted context omitted.
I ran NixOS for a while, before I switched to Apple Silicon, so I consider myself fairly well-versed-enough (although nowhere near an expert) in Nix and the Nix ecosystem. My last four jobs have all issued me MacBook Pros; the last three with Apple Silicon. Ultimately, my workplace setup is what has the most gravity. And the most I can get most workplaces to standardize on is Homebrew for package management of off-th…
So don't propose it? You can run Nix and Home Manager on macOS or any Linux distro. You don't even need root. It works exactly like you describe: it provides its guarantees for all software that you manage through Nix, and doesn't get in the way of software that you don't manage through Nix. Unlike with NixOS, you can run binaries that expect an FHS-compliant system just fine. You can just silently use it and enjoy t…
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 the raison d'être. You need to actively avoid the "value-added" parts (e.g. package options) because latest Homebrew upstream may give you a version that exposes an option that is not yet exposed by the package options, and you can't patch the package with Nix because you're not using a Nix-based package.
Chezmoi is declarative. The templates give me generated configuration. I can rollback anytime I want by reverting Git commits and calling chezmoi apply. It works well within its less-ambitious goals (compared to Nix).
Re: Migrating from GNU Stow to Chezmoi
#125Earlier quoted context omitted.
Your second example i dont understand what you're getting at. This is just a mechanism for the builder to inject credentials during fetch time. The derivation is still content addressed (it's a fixed output derivation). The derivation isn't even marked as impure or whatever. There is just an environment variable that gets injected by the builder into the build env so you can authenticate. This is required to talk to…
I understand in considerable detail what's happening here, having written a conforming implementation of `nix` myself. Silently smuggling environment variables into a builder means the build is not reproducible, nor is it possible to know a-priori whether the build is reproducible. Nix reverts to the same level of guarantee you get from Ubuntu or whatever without the convenience of Ubuntu: Docker is dramatically more…
The whole point is that it allows introducing controlled side effects as long as the output is reproducible.
Bur you're extremely annoying to talk to so I'm not gonna continue engaging. Probably an LLM
Re: Migrating from GNU Stow to Chezmoi
#126I must've tried to set up stow five or six times over the years, in between various hand rolled custom setups. I can't put my finger on why but I set up chez moi & it's been my setup since, much longer than any previous solution. Chez moi is definitely not without its rough edges but it seems to have gotten the subtle essentials right enough for adhd me to not have abandoned it yet.
I used stow for a long time, then tried Ansible, but eventually settled into good old Make. `make dotfiles` just creates a bunch of symlinks, takes 5 minutes, all good and happy. Everything is modular, declarative, simple. Never looked back.
There's roughly two main ways to manage dotfiles:
- symlink
- copy & sync
The 2nd (what chez moi does) is pretty hard to get right from a UX perspective.
Re: Migrating from GNU Stow to Chezmoi
#127Re: Migrating from GNU Stow to Chezmoi
#128Earlier quoted context omitted.
So don't propose it? You can run Nix and Home Manager on macOS or any Linux distro. You don't even need root. It works exactly like you describe: it provides its guarantees for all software that you manage through Nix, and doesn't get in the way of software that you don't manage through Nix. Unlike with NixOS, you can run binaries that expect an FHS-compliant system just fine. You can just silently use it and enjoy t…
> 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…
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" parts (e.g. package options) because latest Homebrew upstream may give you a version that exposes an option that is not yet exposed by the package options, and you can't patch the package with Nix because you're not using a Nix-based package.
You mean build-time options?
You can usually override the version number/URL in your own configuration to get the new version earlier. But new versions land in nixpkgs-unstable with about the same cadence as Homebrew anyway.
Same thing with runtime options. Want `programs.foo.enableNewThing` but it’s not in HM yet? You can just define that option in your own configuration, no need to stop using the value-added module nor wait for HM.
Re: Migrating from GNU Stow to Chezmoi
#129Earlier quoted context omitted.
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?
The chezmoi integration with 1Password is excellent; for those who prefer Bitwarden, it supports both the default CLI (which has some inexcusable behaviours for a security product, IMO) and `rbw` (which is infinitely better than the default CLI). It supports `pass`, `gopass`, `passage`, AWS Secrets Manager, KeePass, and several other approaches.
It was the work of a couple of minutes to enable a secret for a Claude Code API token to be mounted in a VM where I'm running Claude for a project where the value is pulled from 1Password and I can regenerate it and reapply without fear.
If one doesn't have to worry about secrets in one's dotfiles, I'm sure that other dotfile managers including Nix with Home Manager will suffice. I do, so they won't.
Re: Migrating from GNU Stow to Chezmoi
#130Earlier quoted context omitted.
What a snakepit of a comment! I know there are tensions within nix but this feels like a classic case of Chestertons fence at a big scale.
These things really do not have an actual reason. Take for example the Nic people who go to every project with a bash script that uses #!/bin/bash and tells them to use #!/usr/bin/env bash. There is no justification for trying to fix every bash script in existence over the operating system being able to resolve what the "current" bash version should be (/usr/bin/env already has to pick a version). This is pointless O…