Channel overlays while creating systems

[heinwol]

Here's my case: I want to use nixpkgs-unstable channel on my main machine, but nixpkgs-stable on my partner's one due to stability reasons. Flake-utils-plus allows that and it's cool. However, I also want to access my own packages inside partner's configuration. The most straightforward way I thought of was like this (inside lib.mkFlake's argument):

      package-namespace = "my";
      channels.nixpkgs-stable.overlaysBuilder = lib.overlay.create-overlays-builder {
        inherit package-namespace;
      };
      systems.hosts.my-partner's-machine.channelName = "nixpkgs-stable";

However, while evaluating the configuration nix shouts:

error: attribute 'my' missing

It feels like the channels.nixpkgs-stable parameter is being completely ignored. That's quite strange, since the same block of code works for default nixpkgs:

lib/snowfall-lib/flake/default.nix

Lines 173 to 176 in 92803a0

	channels.nixpkgs.overlaysBuilder = snowfall-lib.overlay.create-overlays-builder {
	inherit package-namespace;
	extra-overlays = full-flake-options.overlays or [ ];
	};

And I don't see channels parameter removed in snowfall-lib.flake.without-snowfall-options or anywhere else... Strange!

[heinwol]

This dirty hack works however:
heinwol@1e0e3d3

So I think I'll put up with my own cursed fork of snowfall lib for the time being 😸

[jakehamilton]

Ah, this is a concession I had decided to make in order to keep Snowfall Lib simple and able to handle most things automatically. Having support for multiple different channels makes things a bit more complex and some of the logic may need to be reworked in the system builder. However, you should be able to use the system, package, and overlay builders yourself to produce the output just like Snowfall Lib would do it. This would be more tedious, requiring you to do all the wiring, but it should be possible today.

I'm not sure if systems on different channels is something that Snowfall Lib should support. It may be useful to have, but I don't know how common the pattern is. In my experience, using the stable channel and pulling specific packages from unstable works perfectly fine as a way to balance stability and having certain bleeding-edge package versions.

[heinwol]

Thanks for the reply! You can take a look at what I've done to have minimal sane support for enabling overlays for different channels: heinwol@5e3cdc4. However, that's not what I ended up with due to further problems ;)

I feel like you're right on whether the provided behavior should be reworked. As I see it, it requires a lot of refactoring (which I tried to do myself -- see the following issues -- but daaaaaaamn nix is so hard to refactor, the enemy wouldn't want this) and the gain is pretty minimal for the edge cases like mine... Soooo yeeeah, I believe I could just do the wiring myself

[jacobranson]

I stumbled upon this issue looking for a way that I could utilize separate channels for my macOS and NixOS machines. Ideally, it'd be nice to have the macOS hosts have their pkgs follow nixos-${version}-darwin while the NixOS hosts have their pkgs follow nixos-${version}. Just wanted to throw my support behind a potential future enhancement to allow for distinct channels per OS, or per host.

[LovingMelody]

Would also like to see per-host optimizations. Some of my hosts support cuda while others do not, as well as package optimizations for x86-64-v3

[heinwol]

@LovingMelody you can still add per-host overlays inside each of system configurations, like you would do in vanilla nix. If you only care about several packages this can already be achieved.

[khaneliman]

Ironically, was just looking for how to implement something like this so that I can have my darwin machine track nixpkgs-unstable instead of nixos-unstable.