[feat proposal] Propagate channels to parts of configuraion (modules, systems, etc.)?

[heinwol]

It seems like a good idea to be able to access distinct channels in e.g. modules. Let's say we want some module to work with specific version of pkgs regardless of the system it's being evaluated for. What I have to do now is

let
  pkgs' = inputs.specific-nixpkgs-version.legacyPackages.${system}.pkgs;
in
... # use pkgs'

I feel it's just redundant work since we already declare different channels in our flake. And it'll be worse if we want some specific overlays inside the channel.

Maybe it's a silly request and it will break something if implemented straightforwardly. Or maybe it's already implemented and I'm blind. Your thoughts?

[jakehamilton]

Hmm, I'm not sure how common this is and what benefit it may have over overlays. What are you trying to build?

[heinwol]

Due to hardware issues and stability reasons I have to use 3 different channels for 3 different systems. This can't be achieved by simple overlaying: packages needed for the core of the system have to come from a specific channel. At the same time, I want packages inside environment.systemPackages to always use unstable channel (I love modern software, haha). Why can't I overlay these packages? Well, I have things like cmake or curl there, so overlaying them would cause recompilation of a whole lot of system packages, which could even cause building errors. No, I want to have up to date curl in my environment.systemPackages but leave the version needed for building the system untouched

[heinwol]

As you mentioned in the previous issue, I could use distinct functions of snowfall-lib to create parts of my config and then wire it all together by hand. The problem is lib.snowfall.module.create-modules still is not enough for me as it doesn't propagate channels. Maybe I could add the feature myself, but how do you assess my chances of doing this relatively quickly without refactoring all the snowfall-lib logic and without having my head hurt beyond repair from an interpreted weakly dynamically typed lazily evaluated language? ;)

[jakehamilton]

Coming back around to this, I think there is work that can be done to make sure the functions that take in a package set also pull from that. I think there are a few places which incorrectly are grabbing packages from user-inputs.nixpkgs rather than allowing for a customizable channel. This would be a good step towards more fully dynamic channel configuration by letting users start with setting things up theirselves.