Access system level option from profile level overlays

[alkeryn]

Issue description

Let's say i got a service.xserver.videoDrivers = [ nvidia ]; in my configuration.nix it would be cool to access it from my ~/.config/nixpkgs/overlays.nix so i could have things like

   blender = (super.blender.override {
     cudaSupport = if builtins.elem "nvidia" toplevel.xserver.videoDrivers then true else false;
   });

That can be used with nix-env -i or other commands. because i got many computers which all use the same comon core but then also have imports specific to them, basically i use the same dotfiles for all my computers and have them load on top things that are specific to them. and that would be cool to be able to do the same with my overlays (ex when using nix-env -iA")

A thing to note is that my nixpkgs.overlays = import ./overlays; and my .config/nixpkgs/overlays contains import ~/.config/nixos/overlays i use the same file both for system level and my profile and i'd like to be able to have those options automatically enabled / disabled when doing a nix-env -i for ex

the only way i found to do that is to create a file in /etc and then import it in .config/nixpkgs/overlays

But maybe there is a more elegant way to do that and if there isn't it would be cool there is

[FRidh]

The package set does not depend on the operating system modules. Packages may define their own options, and modules may offer to expose those options, but it is not (going to be) possible to access module options from the package set.

[worldofpeace]

Wouldn't the value of services.xserver.videoDrivers be accessible from config.services.xserver.videoDrivers? We already do things like this in nixpkgs.

[alkeryn]

@worldofpeace No it isn't ^ that's my issue basically, i'd want to be able to access the system configuration from nixpkgs or overlays but services.xserver was an example i'd like to be able to define a scope from configuration.nix and access that scope from a user profile

idk something like being able to define shared.isMyDesktopPc or shared.anything and access it from anywhere (nix-env overlays) would also be nice

[alkeryn]

The package set does not depend on the operating system modules. Packages may define their own options, and modules may offer to expose those options, but it is not (going to be) possible to access module options from the package set.

But that's exactly what i wanna do, not from packages directly (as that would mess with determinism) but from an overlay (read by nix-env and other profile commands)

[alkeryn]

because i want to use the same overlays for all my computers (with nix-env) but have things specific to each computers (using conditions) in the overlays and have those options defined in configuration.nix here are my nix related dotfile for ex https://github.com/Alkeryn/dotfiles/tree/master/.config/nixos https://github.com/Alkeryn/dotfiles/tree/master/.config/nixpkgs https://github.com/Alkeryn/dotfiles/tree/master/bin/shell/env https://github.com/Alkeryn/dotfiles/tree/master/bin/wpc

[alkeryn]

i got something like that

[worldofpeace]

For nix repl you'd need to use nix repl "<nixpkgs/nixos>" to bring in the current nixos config.

idk something like being able to define shared.isMyDesktopPc or shared.anything and access it from anywhere (nix-env overlays) would also be nice

That sounds like nixos modules, and shared.isMyDesktopPc is an option that you could access. It would have differing values depending on which value a host has declared. You could access that value from config.

[alkeryn]

For nix repl you'd need to use nix repl "<nixpkgs/nixos>" to bring in the current nixos config.

idk something like being able to define shared.isMyDesktopPc or shared.anything and access it from anywhere (nix-env overlays) would also be nice

That sounds like nixos modules, and shared.isMyDesktopPc is an option that you could access. It would have differing values depending on which value a host has declared. You could access that value from config.

yeah but by nix repl i spoke about the same scope as ik you can do that for exploring your system but you can't do that from an overlay ^ And no it would be accessible from rebuild switch but not from nix-env -i i need to be able to access from both the same way ^

[deliciouslytyped]

This is probably a bad idea for some reason or other, but you could try importing/accessing <nixos-config>. One of the problems here is that the system configuration could for example contain secrets, so there's no guarantee it should be importable.

Also of note, is that overlays and modules seem to interact badly in some cases, leading to infinite recursion. Can't really elaborate because my keyboard sucks right now.

There should be some sane way to make some variation of this work but I can't think of anything...

I'm looking forward to a decent solution to this with interest.

[deliciouslytyped]

Which is to say, you could try evaluating the configuration locally.

Alternatively, you could try generating some sort of state file, which you read in your overlay.

(I'm only half joking; nixos needs the windows registry? :P)

[alkeryn]

@deliciouslytyped Well that would be cool to have a shared.* namespace in configuration .nix that user profiles can also access or something alike the only solution i fond so far is to describe a file in /etc, put some nix in it and then importing it in ~/.config/nixpkgs/overlays.nix, that works but i was kinda looking for a more elegant way to do that that might be builtin and if not add it. Also since i use the same overlay file for system level and nix level i have to first define a scope in configuration before putting it in the file or it will fail to rebuild switch ^

[alkeryn]

Of course, nixpkgs derivation shouldn't be allowed to use it ( that could break determinism), but i think overlays (user defined) should ^

[alkeryn]

also yeah not only i don't think you can import <nixpkgs/nixos> but on top it is lacking some options like some of them are just missing for some reasons ^^ Also i need the overlay to both work with rebuild switch and nix-env

[FRidh]

Overlays cover only the package set, not NixOS options. Like @worldofpeace showed, you can import the nixos/ modules, in that case from the value that <nixpkgs> corresponds to. I am of the opinion the package set should really not point to the operating system modules. It should always go the other way around. Packages may provide options, and modules provide options that can pass items to the package functions.

[alkeryn]

@FRidh The thing is that it isn't possible to go the other way arround for what i'm trying to do... the only way is to access a system level option from the overlay And a more elegant way to do that than creating a file that contain nix and importing it would have been more elegant.

[alkeryn]

Also it seems you can't import <nixos/nixpkgs> from an overlay

[FRidh]

If you want to achieve

because i want to use the same overlays for all my computers (with nix-env) but have things specific to each computers (using conditions) in the overlays and have those options defined in configuration.nix

then I find it hard to believe that

The thing is that it isn't possible to go the other way arround for what i'm trying to do...

Again, the packages can have options. In the configuration files of the various machines (be it in a module or environment.systemPackages you override the packages with whatever machine specific flags you have. This is the normal way of working.

[deliciouslytyped]

I think something that might been implicit or got lost here somewhere - for some reason I got the impression this was for user level configuration.

[alkeryn]

@FRidh But i want nix-env -iA to also have those override specific to each computer not just the configuration.nix when nix-rebuild switch

i'm using the same overlay file both in my configuration.nix and my .config/nixpkgs/overlays.nix it is just an import

So NO it isn't possible to go the other way arround

[FRidh]

Closing because what you want is not (going to be) possible.

[alkeryn]

@FRidh Is there no actual elegant ways to do that either ?