|
|
|
|
|
by solatic
3 days ago
|
|
> 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 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). |
|
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.