cool article! However, counterpoint: What is a flake?? The article doesnt say...
Is it like a makefile?
Nix flakes are a feature of the nix package manager to make nix packages more reproducible.
Wut. It’s just as reproducible, flakes are mostly just a common unifying API with some extra CLI sugar for usability.
While that is true, it's also r13y on another level: Reproducible evaluation. That mostly stems from pure eval and locking.
In the "before times", you'd get your Nix expressions from some mutable location in the Nix path, so running i.e. a nixos-rebuild on your configuration could produce two different eval results when ran at two different times, depending on whether anything about your channel configuration changed in the mean time. This cannot happen with flakes as all inputs are explicitly given and locked.
You could achieve the same using niv etc. before but that had its own issues.
It was usually recommended to lock to inputs anyhow with all the fetchers requiring a hash which I hated having to manually update & like the UX flakes provides (I really wish they supported more than Git & Mercurial tho). You can still have different evals tho if you point to latest.tar.zstd or other non-hashed thing like a branch where the referred to can change & it won’t reproduce. I haven’t used channels in years, but doesn’t that just refer to the running system, not using Nix to build projects?
I haven’t used channels in years, but doesn’t that just refer to the running system, not using Nix to build projects?
I have no idea what you're trying to say here.
Aren‘t channels for NixOS, and you’d use overlays for building packages? Now you can do that all with flakes.
No, channels are a simply a mechanism for managing what's in your NIX_PATH.
cool article! However, counterpoint: What is a flake?? The article doesnt say...
Is it like a makefile?
Nix flakes are a feature of the nix package manager to make nix packages more reproducible.
Wut. It’s just as reproducible, flakes are mostly just a common unifying API with some extra CLI sugar for usability.
While that is true, it's also r13y on another level: Reproducible evaluation. That mostly stems from pure eval and locking.
In the "before times", you'd get your Nix expressions from some mutable location in the Nix path, so running i.e. a nixos-rebuild on your configuration could produce two different eval results when ran at two different times, depending on whether anything about your channel configuration changed in the mean time. This cannot happen with flakes as all inputs are explicitly given and locked.
You could achieve the same using niv etc. before but that had its own issues.
It was usually recommended to lock to inputs anyhow with all the fetchers requiring a hash which I hated having to manually update & like the UX flakes provides (I really wish they supported more than Git & Mercurial tho). You can still have different evals tho if you point to
latest.tar.zstdor other non-hashed thing like a branch where the referred to can change & it won’t reproduce. I haven’t used channels in years, but doesn’t that just refer to the running system, not using Nix to build projects?I have no idea what you're trying to say here.
Aren‘t channels for NixOS, and you’d use overlays for building packages? Now you can do that all with flakes.
No, channels are a simply a mechanism for managing what's in your
NIX_PATH.A flake from cornflakes