Please check that this is actually the case. Setting nixPath will only take effect after running nix-darwin rebuild (as for NixOS), and only when you re-initialize your shell.
It won’t work if you upgrade your system from an older configuration when changing both nixPath and your mkShell.
The first machine has a warning about /nix/var/nix/profiles/per-user/root/channels but not the other. Something must be different between your two machines. A channel is different or something.
Does nix-shell use flakes? How would nix-shell know to map <nixpkgs> to what is in the system config flake?
You might get more diagnostics with nix-shell --pure.
I think you are going to find that nix-shell is pulling in whatever channel info is set for each user (and machine).
Consider replacing/wrapping shell.nix with a flake.nix and using nix develop. Although, this still won’t be connected to the system config nixpkgs; flakes are meant to be isolated from system and environment dependencies.
darwin https://github.com/LnL7/nix-darwin/archive/master.tar.gz
nixpkgs https://nixos.org/channels/nixpkgs-unstable
So I added darwin also and ran nix-channel --update and both are working as expected. I guess the main issue here was my lack of understanding that channels are not managed by flakes. I thought they were so I assumed that both machines should behave the same even inside shell.nix but that was not correct.
So what does nix.nixPath do then, because I’m confused?
It sets the NIX_PATH variable, which should have the effect you’re expecting. I’d guess that it isn’t present in whatever shell you’re running nix-shell in, for some reason, e.g. because you’re not sourcing the global bash profile, or something along those lines.
As a friendly tip, I’d recommend removing the imperatively set channels entirely. Then you only have your declarative config, and if that isn’t working, you get an obvious error rather than this confusion.
It is not always as trivial as wrapping the shell.nix in a flake.
Debugging “legacy” by making it non-legacy anymore is often not trivial, not paid work and there are quicker ways to debug the problem.
Whenever “diamond paths” appear, the first thing to check is the NIX_PATH and especially to also check the “unnamed” entries, which resolve through their content.
Personally I got back control. I manage my nix.nixPath through the system configuration and all of its entries point to well controlled locations. All entries are “named”.
That is the proper fix to avoid interference through nix-channel.
Huh, so I take it that means imperative channels take priority? Good to know, I’d never tried this before. Another little gotcha to add to my grab-bag of “help, I somehow unreproducibilized nix” gotchas
I’m guessing this is because /nix/var/nix/profiles/per-user/root/channels is added to the end of the variable. Maybe this could be changed to prevent problems like this in the future?