I have a new laptop that I’m trying to set up with flakes, nixpkgs-unstable and hyprland. I keep getting an error when building the system, error: The option wayland does not exist but nixpkgs is set to unstable. When I run nix-instantiate --eval -E '(import <nixpkgs> {}).lib.version' I get "25.11pre-git". I thought unstable was 26 something? Should I just load nixpkgs from a more recent branch? The only solution I’ve seen to my particular error, is updating to unstable, but I’m already on unstable.
That will grab nixpkgs from your channels, and yeah, that output is fishy. If you’re using a flake to configure your system, that should point to your nixpkgs input, but perhaps you haven’t switched since you last ran nix flake update.
If you’ve not been running nix flake update to update your system at all, now is the time.
Other than that, share your code - I’m just guessing, all of this depends on what you’ve actually done. Until someone buys me a crystal ball I can’t help with these kinds of posts
Also, while I’m at it, there is a module for hyprland in nixpkgs. Use it unless you know what you’re doing - I’m aware the hyprland upstream recommends using their flake, but you really don’t need more bleeding edge than nixpkgs-unstable, and using their flake just introduces more potential for headaches - like the one you have now.
If you’re using a distro, have the distro manage your software integration for you, unless you have very specific requirements.
Even more of an old man yelling at clouds
Anyway don’t use hyprland to begin with, it’s almost identical to sway in terms of features (yes, sway works just fine on nvidia - nvidia themselves actually test against sway, not hyprland; sway may not support nvidia, but nvidia support sway), but deliberately works against the ecosystem.
It’s why there are so many hypr-specific packages, you often can’t use the generic wlroots implementations.
That’s that upstream’s general MO - break stuff and claim it’s everyone else’s problem for not being smart enough, hence the recommendation to use the flake.
Makes sense. Well, whatever window manager I end up with, I guess I’d like to know how I managed to have unstable/not unstable, if you’d be kind enough to look over my flake.nix
I’d need to see your flake.lock as well. I’m not certain what you have is wrong.
To understand what I mean I guess you need to understand how <nixpkgs> gets resolved. That’s special syntax telling nix “look up the path for this on the $NIX_PATH environment variable and return it here”.
So at evaluation time that will be expanded to something like /nix/store/<bigolhash>-source, and that location comes from the $NIX_PATH. That’s why with flakes this syntax is prohibited, unless you use --impure - it needs to read from an environment variable that may change.
This is relevant because by default NixOS sets up $NIX_PATH to point to the flake input it is built from, which means that your <nixpkgs> resolves to whatever the last nixpkgs you evaluated was. I.e., the one from your last sucessful activation, not the one currently in flake.lock. So it’s entirely possible - likely, even - that your setup is completely fine, just not activated yet.
It is also possible that you haven’t learned how to use nix flake update yet, and that you are in fact on an outdated version. It’s impossible to see without your flake.lock.
With that said, there are a few things to point out from what you’ve shared so far. I should just write a linter, but here goes tlaterlint - some of these are more nit-picky than others:
You can skip any inputs you’re not using in your outputs from this attrset, they get passed along with inputs anyway. Given the snippet you’ve shared, you could make do with:
… and probably drop home-manager and hyprland, too, if you follow my later advice. This is probably my biggest nit-pick, but looking at your code I don’t think you understood how this works, so I thought I’d explain it.
This is a bad idea. home-manager.lib contents will override nixpkgs.lib contents. If you insist on doing this, do it the other way around, but honestly just call nixpkgs.lib or home-manager.lib where needed, it saves you barely any characters in exchange for being supremely confusing.
… or better yet, don’t do that to begin with and move the logic for picking correct systems into ./pkgs/. Also, you’re importing a flake literally for two list elements, I think that’s a little silly. Especially for a NixOS config flake, consider writing out the systems you want to support instead, if you don’t just hard-code it to just x86 (and I’d advise against pre-generalizing, you can really easily add a stanza like this if you ever need to target a raspberry pi or something).
You don’t need to use self.outputs, self transparently contains all your outputs. So drop any passing around of outputs or self you do and just use inputs.self.<packages|nixosModules|homeManagerModules|...>.
Don’t re-export the contents of other flakes. If you depend on your flake (which with a NixOS configuration flake you should almost certainly not), just make the dependant flake import its own nixpkgs or home-manager and use .follows to equalize the inputs.
You can drop the import, because the module system will correctly handle being given a path, so this increases eval time a smidge when it doesn’t need to - in your defense, this is quite counterintuitive, I also only learned this recently.
You already have inputs.hyprland. You can of course pass that through twice, but that’s not particularly clean IMO, just let-bind it with inherit (inputs) hyprland if you end up rewriting inputs.hyprland a lot downstream.
Bit of a pet-peeve of mine, but people writing this indicates to me that they’ve not grokked how the module system works.
… you can of course put that in configuration.nix as well. Either way, such business logic has no business (heh) being in flake.nix, just get it out of there.
Thanks for that. I incorporated your advice as much as I was able. I tried the nixos module for hyprland, and then sway, and finally settled on gnome! But my system flake is reasonable now.
