Update to 25.05 creates nixpkgs.config / home-manager.useGlobalPkgs conflict warning

Hello, I just updated to 25.05 and after fixing all the small deprecations and packages updates, I am left with this warning:

evaluation warning: odin profile: You have set either `nixpkgs.config` or `nixpkgs.overlays` while using `home-manager.useGlobalPkgs`.
                    This will soon not be possible. Please remove all `nixpkgs` options when using `home-manager.useGlobalPkgs`.

After doing some googling, I am still unable to fully understand why this is showing up. I am also very confused on why it is only showing up now. I do not have home-manager.useGlobalPkgs set in my config. Any guidance on where in my config I should look to fix this problem, or any way to get a trace for where this warning is originating from? Thanks in advance.

It’s always been supposed to show up but there was a small bug in the assertion that made it not actually work.

This bug was fixed, however, fixing that bug would mean breaking backwards compatibility, meaning your configuration would now be broken if it had remained an assertion.

So it was added as a warning to preserve backwards compatibility so you can fix your configuration before it breaks.

It’s new because the deprecation is basically introduced with 25.05. Stable release schedules working as they should, basically - you just need to now fix it.

The good news is, your configuration has always been broken; the stuff the message is talking about has not worked for at least 4 years. It’s just that soon the warning about it will become an error so people don’t accidentally do this without realizing it’s not working anymore.

You most certainly do, nix evaluated an assertion that says you do. Even if you think you don’t, your home-manager activation script will in fact use the global pkgs, so whatever is setting it needs to be fixed.

It should be where you declare your settings for the NixOS home-manager module. Depending on how crazy you went with third party templates and other stuff, this may be buried a few projects deep. It’s why I don’t really suggest using templates unless you know and understand what they do. Or maybe it’s just in your own code and you don’t understand that either.

If you can share your code we can help look for it. grep is your friend, or ripgrep (rg) if you like modern tools.

Not really, sadly, since the module system is implemented in nix that kind of information cannot be passed through. Nix doesn’t feature introspection, so NixOS/home-manager is stuck with dumb asserts.

2 Likes

With all the above in mind, you probably do want to keep useGlobalPkgs enabled if you use HM as a NixOS module (i.e. not standalone), because it’ll prevent you having two different nixpkgs instances and the higher memory usage, longer builds, and possible incompatibilities that’d come with that. Instead, just move your overlays and config settings to your NixOS config.

On the other hand, if you’re using standalone HM, do not enable useGlobalPkgs (I’d hope HM has a check for this, but just in case…).

nixos-option homeManager.useGlobalPkgs, but again, I’d leave it as-is.

2 Likes

The option simply does not exist outside the NixOS module, so that’s not a concern.

2 Likes

I am using a third party template and am now realizing that this is where it originated from, thanks to the nixos-option command. I should clarify that I do know what the option does, and after looking at it in the flake template I am using (snowfalllib if your curious) I most definitely want to keep it on. So now the question is, what do I have to remove to keep as is. I am guessing that this is coming from the fact that I use pkgs as an input to some of my homemanger modules. Is this a correct assumption?

No, somewhere in your home-manager config you set one of these options:

I’ve still not gotten used to nixos-option existing. Sadly I don’t think nixos-option works for home-manager modules, but you can try it and tell me!

Neither of those options has ever worked when you set useGlobalPkgs, just remove them, there will be no change in behavior.

If you actually intended for those settings to do something, migrate them to the equivalent settings in your NixOS config.

Thank you for all the help, I feel like I am almost there. After greping my personal project, no mention of any of those options exists. After searching through the template, useGlobal is set, but the other two are not. I did find an option called channels.nixpkgs.overlaysBuilder. Is this what is causing the warning? If so I guess I will have to change my template.

Edit: I should mention I am using flakes.

Possibly. It’s hard to know without asking upstream or going code delving; these third party templates build their own abstractions on top of the module system, which obfuscates things quite a bit. It’s possible that stuff gets naïvely passed down to the home-manager option.

The correct course of action if you want to continue using snowfallib is to raise an issue upstream.

My advice is to stop using snowfallib, you probably don’t need leaky abstractions on top of abstractions, and if they weren’t in the way you would never have been confused about that error message (if you even got it in the first place). If you need help migrating, feel free to ask, it may be a bit hard to figure out what you were even relying on it for (though running your config in a VM to test it out is luckily not too hard).

But this is unrelated to this specific issue; this is probably just an upstream bug, and you should treat it as one.

1 Like

Thanks, then I will get to migrating. I was mostly using it for convenience of organization cause I was too lazy to build a proper file structure for my config, but probably better I just bite the bullet and do it right. Semi-unrelated, but any chance you have a link to a file structure for your nix config that you prefer?

Eternally WIP and probably more complex than need-be for most use cases, but sure: GitHub - TLATER/dotfiles: Dotfiles deployed with nix/home-manager. Feel free to take what you like!

Ignore basically everything in home-*, the rest I’m reasonably happy with, +/- some reorganizing of module contents (e.g. wireguard should be in networking, and not use wg-quick, but it’s defunct anyway).

1 Like