1000 sats \ 0 replies \ @jurraca OP 9 Feb \ parent \ on: Nix Office Hours NixOS
yea, i'm not sure i have the whole picture but here's the tradeoff:
- flakes are very cool in the sense that they're more generic than just throwing a nix expression with source code. They're really another layer that builds on top of Git, where you commit the build configuration with the source code. So any project with a flake can be discovered via Nix without the user/caller relying on nixpkgs. And then you can compose flakes from different projects as you see fit.
- Flakes are a step away from the nixpkgs model which is more about "running a package management repo" . In Nixpkgs, I don't have to care about which version of nixpkgs i'm running, the packages will compose together nicely. That's what nixpkgs guarantees! With flakes you have to be careful not to pull in diff versions of nixpkgs etc. So non-flakes world is more about creating a monolithic set of package recipes that are guaranteed to work now and at any point into the future. This article goes into this a bit.
I get that it's super annoying to be faced with two models when you walk into Nix, but I think they're two approaches and both work for diff purposes. Infinite respect for Nixpkgs (the mothership) and also use flakes for my projects and machines.