Is it wise to start spending significant parts of my Nix-time-budget on flakes?
Details
Doing anything in Nix causes me untold pain and suffering, and wastes absurd amounts of my time … unless it follows a path already well-trodden by me personally. I put myself through this because I know that, after all the pain, suffering and wasted time, if eventually I reach my destination, I will have a robust, reliable, reusable solution which will save me even more pain, suffering and time in the long run.
After a few superficial glances, flakes look really appealing. I really want to start using them. However, they are still experimental. Hence my dilemma:
Do I continue using stable Nix to solve my problems, giving me less satisfying solutions that flakes would afford, solutions which I will then probably throw away in favour of flakes in the future?
Do I start using flakes now, at the risk of having to throw my solutions away in the future when flakes are rejected or significantly changed.
The time I can afford to spend on fiddling with Nix is limited, so I’d really like to choose the optimal path.
I know that predicting the future can be difficult, but can you provide any information about the status of flakes that might help me choose wisely?
I did transition to flakes for my home-manager and nixos configurations, and am pretty happy with how it currently works.
But I find my self still using some of the nix-* tools, because the “nix *” commands are not completely on par (build --dry-run, for example). But the path is done for 95% for nixos (personal guestimate), about home-manager, I could not find a way to use their scrit, so I build my derivation from the flake them, run the generated activate script.
One thing that is not completely clear for me is how to propagate the nixpkgs flake for the system including my overlays, but it is not a big deal.
That being said, you may need some time to convert your configurations if you do strange things like combining multiple channels to build one or the other configurations
That’s certainly a possible danger, I don’t know if it’s a likely one. I’ve previously used flake-compat to make sure that tools and workflows that look for default.nix and shell.nix are still viable in a non-Flake-enabled Nix install.
This is where I’m at too. The required changes lives on a different Git branch because I haven’t finished making nix-darwin or home-manager-on-OSX play nicely yet. I am finding that the Flake pattern is much nicer to work with even as a niv user, so I’m starting to open-source Nix definitions slowly that I would not have considered pre-Flakes.
I’m not on my NixOS host atm but there are some configuration.nix settings about IIRC nix.registry that seem pertinent. It should at least make sure that your system’s nixpkgs input is followed by any other flake you use that does not specify that input precisely, but that does not address overlays, I don’t believe.
In my opinion, as a Nix user, Flakes are safe to adopt from a functionality standpoint. They are basically just some syntax: https://github.com/colemickens/nixos-flake-example (a demo showing flakes and regular nix-build building the same store path from a configuration). Also, you can achieve almost the same functionality with hand-written fetchTarball calls, or by using niv.
However, there are some things flakes addresses that aren’t easily addressed without flakes. Consider, troubleshooting a nix-env -iA command failing for a one-off user, with Nix today…
wait, what is your NIX_PATH set to?
wait, what do you have in ~/.config/nixpkgs or overlays/? or wait, what about overlays.nix?
oh hey there’s ~/.config/nix too, but it probably doesn’t matter, hopefully?
what does nix-channel --list say?
Oh wait, you’re using nixos-rebuild, aka you’re probably actually using sudo nixos-rebuild… so you have to know to actually reconfigure your channels with sudo nix-channel
oh and of course watch the sudo/sudo-less for (sudo) nix-channel --update too, you probably need both!
These things are not issue with flakes. Flakes bring locally, explicitly defined dependencies to Nix projects, and enable pure evaluation by default. That alone makes it easy for me to adopt flakes.
(minor) it’s annoying to have to use nix-shell so aggressively to deal with small behavioral changes in the nix CLI (nix copy building derivations for example), or to have --experimental-features at all, etc, etc.
Retrofitting flakes onto a repo isn’t hard in my experience. Add a flake.nix, plumb through outputs from default.nix that you want exposed, replace unversioned fetchTarball calls with flake inputs, remove uses of currentSystem.
As for “propagating overlaid nixpkgs”, I just expose it as an extra output attribute in my nixcfg repo. nixcfg#packages is just my config-local packages, but nixcfg#pkgs is a full nixpkgs with my overlays applied so that I can run nix profile install nixcfg#someOverlayPkg and have it work.
Even though I’m using nixUnstable on my machine now and I enjoy hacking with Flakes, I’d advice against using this feature now unless you are a “power user” or at least someone who doesn’t have a problem with getting your hands dirty in case you stumble upon problems.
Let me briefly explain why:
you’ll have to expect things to break: flakes are (AFAIK) not yet well-defined and still in active development. Just to name an example, nix develop was previously named nix dev-shell on master. As there are no changelogs, you’ll have to figure out things like this by yourself.
I wouldn’t consider nixUnstable stable yet: since development happens on master there are a lot of new changes going in and potentially introducing new regressions. A recent example would be nixUnstable: 2.4pre20201102_550e11f -> 2.4pre20201105_387f824 by roberth · Pull Request #102932 · NixOS/nixpkgs · GitHub where I realized during testing that nix build (and nix-build) didn’t work anymore due to some deadlocking during IFD builds (IIRC) and I had to roll back to an older generation of my system.
in the future when flakes are rejected
I don’t think that this is very likely: a lot of parts of the infrastructure (e.g. Hydra) are based on flakes, so throwing all of that away is IMHO rather unlikely. The actual risk stems from breaking changes IMHO.
Please don’t get me wrong though: I don’t intend to rant on the development happening here. I try to actively contribute to this ecosystem because I like it and I enjoy working with it. I mainly want to make clear that if you’re an “average user” with “limited time” (as you said originally), it’s (at least in my opinion) not (yet) the time to switch.
Can you give more details on your problem with regard to nix copy, I don’t understand what you expect when copying something that is not in the store? Plain failure?
In nix stable, nix copy ....drv --to file:///tmp/store copies just the derivation. In nix unstable, it will build and copy the output unless --derivation is passed. This is #3696.
Wasn’t the flakes RFC withdrawn?
Is it still developed?
Will there be a new request for comment?
What’s the timeline?
It would be cool, if some of the developers in charge could say a word or two about those questions!
I’ve been working on a side project for the past couple months to implement a friendlier package manager on top of Nix (happy to discuss details in a separate thread if anyone wants to know). It is 100% flake-driven. I know the flake RFC was technically “withdrawn”, but I wonder if that is because it’s already so widely used that it wasn’t necessary anymore?
I’ve seen lots of flake-based code in both nix & nixpkgs repos, so if they are going to pull the feature out that will require a lot of work.
I started out developing with both unstable and stable nix installed. I do NOT recommend this approach. After developing for a month or two in a VM with only nix unstable I went back to my primary machine, blew away the stable nix installation and went whole hog on unstable. I haven’t run into any problems with it so far, save for a strange derivation issue I’m having right now. I don’t know yet whether it is actually related to unstable nix or if I messed something up, still need to look into that (side projects and all).
I agree with typetetrisr that it would be good to hear from a maintainer on this. There was a lot of movement on the flake front earlier this year (blog posts from @zimbatm, tooling from @nmattia and others), but it feels like it’s been mostly silent since then. Can anyone please lend some input?
I’ve been working on a side project for the past couple months to implement a friendlier package manager on top of Nix (happy to discuss details in a separate thread if anyone wants to know). It is 100% flake-driven. I know the flake RFC was technically “withdrawn”, but I wonder if that is because it’s already so widely used that it wasn’t necessary anymore?
It was because «we do not need RFC for experimental feature», and there were some questions in the process of being discussed cut off by this, and it is unclear what is the roadmap.
I agree with typetetrisr that it would be good to hear from a maintainer on this. There was a lot of movement on the flake front earlier this year (blog posts from @zimbatm, tooling from @nmattia and others), but it feels like it’s been mostly silent since then. Can anyone please lend some input?
The RFC process is also useful as a tool for discussion, and we gathered a lot of useful feedback from it. For now, flakes has been merged into master, guarded by the experimental flag. With the idea that it will go through the RFC process again before getting unmarked as such.
Flakes itself is still changing, for example it recently acquired a way to have per-project configuration. Eelco is also exploring to use TOML as a way to simplify the entry-point.
Note that I am not directing that project and am just reporting what I have seen. All I know is that work is still ongoing. Looking at the repo activity it also seems like a new Nix 2.5 release will be cut soon.