Wrote thoughts about how Flakes got to the point it is.
There’s also some thoughts about what it means to me, in reality. And some opinions.
EDIT: Since I’ve been asked: this is not a direct response to any other post, but a write-up I was working on over the past weeks.
The central point appears to be that the integrated festures in question aren’t mature or aren’t “finished”, but there is scant evidence provided to support that claim. Many people use flakes right now and aren’t complaining about stability issues or bugs. I was anxious and didn’t migrate my config to flakes for over a year because it was intimidating and scary, but once I did, I realized how simple and easy it was and the new CLI and lock files are great. I look forward to channels going away.
The central point is that many are, or are close to be, but held back by either other less finished features, integration between features, or due to lack of resources to properly evaluate and determine if it is something that can be worth supporting in the extremely long time.
EDIT: Forgot to state that the vagueness around claims of what is and isn’t stable is by design: it doesn’t matter for the message. The message is that it’s too much all at once. Flakes is being blocked by itself.
(Forgot to reply to the other half)
I was anxious and didn’t migrate my config to flakes for over a year because it was intimidating and scary, but once I did, I realized how simple and easy it was and the new CLI and lock files are great. I look forward to channels going away.
Channels is an overloaded terminology. I suspect this is about the nix-channel helper that uses profiles to “pin” a repo into the Nix store using the Nix profiles system.
Channels were never necessary. It’s been 6+ years I’ve setup NixOS and I have only used channels in the beginning month or two, before focusing in on the intrinsic problems with managing them. So make sure you don’t confuse Flakes with them being strictly a replacement to nix-channel, or being only about locking inputs.
And I don’t think that vague fear of the unknown is the main issue for anyone having issues with Flakes. There are many legit reasons to not use Flakes yet, even the simplest one being that it’s not being marked stable yet.
Here’s a story to support “monolith” part:
Where I work, we use nix as a build system. One of the main things that separates nix from real build systems (ones designed for that from the beginning) like make and bazel is that the real ones detect the rebuild set quickly. Nix’s evaluation slowness here is a real problem, as a result we wind up with parallel ghc --make or ninja systems for interactive use. There was occasionally the thought that this could be open-sourced and could be a plausible alternative to bazel which had just been open-sourced at the time and had many limitations. It didn’t happen due to not enough time, but slow evaluation was definitely one of the things at top of mind that made me think it wasn’t worth allocating the time.
When flakes was first announced it seemed like it could fix this by caching unchanged nix files, and maybe it could have. But it seems like it wound up too tangled up in the other aspects of flakes and is not general purpose. Of course to use any feature in a chaotic open source project means you have to be willing to do patches to adapt it to your case and fix bugs, but for flakes my impression is that this would be working against the grain of their design and probably a significant amount of work, and would not be acceptable upstream. So far I haven’t even seriously looked into it, but would like to some day.
The new nix profile subcommand which replaces the nix-env command for installing packages non-declaratively lacks a simple way to uninstall packages for example. Say that you install a package with nix profile install nixpkgs#hello (why nixpkgs is the default flake?), then you have to list the packages and use the nix store path of the package to uninstall with nix profile remove /nix/store/...hello.
Maybe this issue since the last time I tried but that seems bad ux.
the manual has
• Remove a package by position:
# nix profile remove 3
• Remove a package by attribute path:
# nix profile remove packages.x86_64-linux.hello
• Remove all packages:
# nix profile remove '.*'
• Remove a package by store path:
# nix profile remove /nix/store/rr3y0c6zyk7kjjl8y19s4lsrhn4aiq1z-hello-2.10
nix profile remove legacyPackages.x86_64-linux.hello which is the attribute path for nixpkgs#hello, works. For consistency it would be good to special-case legacyPackages here too.
Don’t you think it is a little verbose still? At best should be nix profile remove nixpkgs#hello.
I really hope this PR gets more attention. It’s a step in the right direction. Quickly iterating on the nix profile implementation might make it a good alternative for brew and others. Newcomers will want to have an imperative way to install packages.
That said, it also shows that even doing a single step takes quite a bit of ‘grabbing attention’-effort. Flakes indeed did too much, but straightening out the kinks seems to take way more effort than the original implementation did.
More nix profile kinks: `nix profile` has bad UX · Issue #7966 · NixOS/nix · GitHub
20/80 rule, isn’t it?
I read through the PR, it’s a bit hard to grok the specifics of the heuristic without knowing nix internals too well.
But if I understand it correctly, does this not potentially result in the same issue nix-env has where you can accidentally downgrade packages, or replace a package with another, if the heuristic happens to match up two similar package names, especially if names change over time? It seems to just match a prefix specific to nixpkgs, and then use the package pname to see if they’re the “same”.
Not really, it is more about the initial implementation just railroading something for one usecase, and then getting things right by people who don’t have access to as much railroading gets ignored too long.
Could we move this discussion to the PR itself? I think it is very off-topic here 
Could we move this discussion to the PR itself? I think it is very off-topic here
Agreed. Though the discussion about flakes and its experimental status is related.
I fully agree with @7c6f434c . I’d like to add that the CLI is flagged as experimental: people are advised against using it and thus is documented sparingly. At the same time, contributors try to keep it mostly backwards compatible. You need complicated tests to ensure backwards compatibility. Dropping backwards compatibility? That probably will start long discussions.