I just finished converting my system configuration to use flakes. A lot of the help/discourse around flakes has involved using home-manager’s nixos module. This is unfortunately not an ideal solution for those of us that use nix on Fedora, Arch, Ubuntu, etc. I’m using a variant of ryantm’s home-manager template with eelco’s flake-compat in order to use flakes in a way slightly more flexible than setting NIX_PATH in dev-shell.
if you own the dotfiles and no one will be depending on your Nix expressions; what’s the benefit of Flakes at all?
The benefit of Flakes is in sharing expressions; it makes everything as if it was wrapped in callPackage and you can have specificity of your Nixpkgs commit. I don’t see the cost for home-manager though where you are the sole consumer.
Niv or specificying the nixpkgs commit inline get you as much bang for your buck in home-manager configs.*
Personally, I used to use niv to version my nixpkgs checkout, my overlays, etc. Flakes can subsume this functionality, and I think it’s more ergonomic to boot. Not to mention, significantly faster in my experience. It’s also buying into the future direction of the nix ecosystem, and makes integrating with other flakes easier.
This was also something I’d seen asked about on IRC, discourse, discord.
I pretty strongly disagree. Flakes have benefits without requiring sharing code, I think this seen in the number of people converting their personal repos to flakes.
Pure evals, locally fully specified inputs, actual portable reproducability. These have every day benefits beyond idealism. Nearly every other day I see an issue that requires more back and forth and confusion than if flakes were simply being used (the most recent is the one who wants to “reinstall” but wasn’t sure what nixpkgs rev they were on. Just … never an issue with flakes).
Not sure how ergonomic it is given how complex the solutions are so far
I can’t figure out what this means?
(And knowing your nixpkgs rev isn’t actually sufficient. You can have random impure imports. You’re affected by local nix configuration and local overlay configurations. This is exactly why flakes is useful and powerful.)
Your example just boils down to fetchUrl with a commit for nixpkgs or niv to manage dependencies.
I see the benefits for shared repositories in defining what’s included (modules vs attributes) but my original claim was that it’s diminishing returns for home-manager.
Sure, and then I specifically listed a number of other flakes features, all of which (can) apply to home-manager builds, all of which come up regularly in the course of supporting users in IRC/Discourse… that are not usually found in non-flake builds.
I’m still curious what is “cost” is that you refer to, or what is “complex” about flakes; I really just don’t understand. It’s the same info you give niv with extra benefits?
I know that a number of people switched to flakes specifically because pure evals lead to faster iteration on configurations.
I will sit down and give nix flakes an honest shot once it makes it into the 2.0 release.
I guess I’m just being grumpy about it
The “cost” i was referring to is that there is a lot of discussion on how to adopt a pattern that I still can’t point to a single documentation page or blog entry that really spells out the full value add.
This is a good approach to point out, and I’ve seen this in use. Could you clarify a bit on how you’re structuring overlays that are pass to home-manager? I don’t see where emacs is defined in your inputs, and I also have several non-flake overlays.