My biggest issue with Nix flakes right now is the way it integrates with Git.<p>It insists on copying the <i>entire</i> repository into the Nix store (which makes all of its content world-readable!). Even if your flake.nix is in a subdirectory of a monorepo, the entire monorepo will be copied into the store every time!
I'm a casual nixpkgs contributor. Flakes are like the embassies Nix sends out into the OSS world. Discussion about building the application are kept with the application, nuances and patches can be discussed with the actual authors.<p>Remember the debian SSH packaging snafu? The application authors weren't involved. (edit: see below)<p>Nixpkgs is like the state department, a central unifying hub, great to bootstrap the package ecosystem (ten years old now), but it needs to spread its wings.
So, did Nix actually adopt flakes ? Because last time I checked, it was still an experimental feature that everyone insists on using, but… it's still experimental, which means you have to make effort to use it.
This probably goes against the flow, but I tried NixOS on a VPS and I found the tools to be inscrutable. Was so confused about Nix packaging and whether to use Flakes.
Flakes rule, impure eval drools.<p>But also, my "personal config" has two dozen imports and overrides nixpkgs on most of those. I have a list of complaints regarding flakes that is only dwarfed by 6+ year old general nix issues, but I could never go back.
the article does a good job of explaining why something like the flake system was necessary, but man oh man does the particular thing we wound up with have issues.<p>you can smell from a mile away that they were engineered to solve widely-experienced problems... as experienced by a single company, with an existing, idiosyncratic set of methodologies. and they just happened to get the blessing because eelco was at that company. unlike nix proper, however, where eelco had the entire internet for feedback, the core design of flakes ossified before the world at large had reason to care about them.<p>it doesn't help that nix's command-line ux is currently super splintered as a result, and while that will be ironed out in the long run, the thing in the name of which those tools got splintered is rather insulting.<p>i love nix but god damn this is the stage at which i'd take someone to couples counseling
I’m surprised all of these systems combine build logic and dependency graphs in the same config. It seems like flake might be a step in understanding these things are only tangentially related.<p>I would like to see composability of graphs (and other set operations on binary package repos) integrated into more dependency management systems.<p>FreeBSD is my server of choice and I’d love to say: create a package repo with my config package and it’s dependencies and nothing more and deploy from that knowing a million other dependencies can’t be pulled in (e.g. give me a new jail that pulls from subset).<p>It’s probably something I should prototype one day.
I think the second point (nix flakes avoid 'stateful' channels) is the more compelling one. I don't recall an easy way for ensuring channels on different systems pointed to the same value; and flakes basically do what Niv did. And, it's much nicer to just install a flake, rather than having to add channels.<p>I'm glad to see the first point (flake.nix provides a consistent interface) mentioned. The consistent interface allows for the cli to be much nicer; `nix flake show` can list the outputs.
This is a bit of a unnecessarily provocative title, since the question of whether or not to promote the 'experimental' flakes system and replace the channels mechanism is still an active and controversial one in the Nix community. There hasn't been any significant news on this front recently; this article simply explains why flakes were introduced as an experimental feature.
I find the default way to work with nixos to be a lot easier to use compared to flakes. I am sure flakes are great and all but as with everything nix you can't just integrate it into your normal flow, you have to jump all in with it. I don't think that is a positive.
Am I the only one completely confused by the examples that appear to put command line arguments after shell end-of-line comments? Is that not a typical shell?<p>example:<p><pre><code> nix run .#cowsay -- flakes are neat
</code></pre>
Some explanation of what the heck this means would be really useful.
I prefer Flakes non-Flakes, but it’s disappointing that you can’t specify mirrors unlike the fetch* commands. Things go down on the internet & mirrors are a way to cover that sitution. There’s nothing like a failing CI because the one of the origin’s servers are down.