Does the channel / commit / branch set in a flake also apply to commands such as nix-shell or nix-env? If not how do I set it?
Also, when I set nixpkgs.url to github:nixos/nixpkgs/nixpkgs-22.05-darwin, will rebuilding automatically fetch the latest commit of that branch and will commands like nix-shell automatically use the latest commit or the one that the system was built from when rebuild was last executed?
No, not by default. The “system channel” is in fact just what nixpkgs is set to in NIX_PATH, so we need to set up nix.config.nixPath so that the nixpkgs entry points to the version of nixpkgs provided by our flake. @NobbZ has the most correct implementation of this I’ve seen:
This avoids some pitfalls with using store paths in the nix path, and also sets up the flake registry so nix shell nixpkgs#foo does what you think it does. I honestly think this should be set by default, but we’re not there yet.
It will make any invocation of <nixpkgs> point to the nixpkgs maintained by the flake, which is what most old nix commands use. You can then remove any channels you used with nix-channel (andsudo nix-channel), and all nix commands will still function.
You should probably also use the new commands where possible, though
Huh, interesting. I’ve not been paying attention to those suggestions, so never noticed.
I think I’m still partial to removing the root channel, simply because it prevents the usual issues of accidentally installing things from channels you’re not expecting, as well as the issue of forgetting to update something you don’t regularly use. Especially so if it will actually have an effect on the running system.
I wonder what it would take to file out edge cases like this and clean up the workflow of making a full system depend on flake inputs upstream. I guess it will be a bit painful for as long as we have both flakes and channels, since the tools that continue to use channels will probably continue to see development that doesn’t test the edge case of what happens if there isn’t a root channel…
I guess for the moment the suggestion should be to switch to nix-index, or turn off the fancy suggestions altogether?
I do not think flakes really know or care about channels, they just track a branch in a Git repository. And the fact that some branches are updated when channel advances is not really expressible in Git.
Lack of command-not-found behavior has bugged me ever since I deleted my channels, so I made a rather more involved solution which always gets the programs.sqlite associated with the exact commit your input is set to. See the commit to my personal config repo here:
Assuming you follow a ref which corresponds to a channel, I think this should always work, though integrating it into your own config will take some adjustment.
my.lib.mkShellScript is a minor convenience wrapper around pkgs.resholve.writeScript. In this case, all it really does is add the interpreter attribute.
hred is not packaged in nixpkgs yet (A shame. It’s the best html/xml data extractor around), but node2nix handles it with no tweaks. Or you could use xq from pkgs.yq to accomplish the same task. EDIT: It’s in nixpkgs now.
I probably should. I didn’t at first because I wasn’t familiar enough with nixpkgs’ node stuff, but I could figure it out.
that only works if you’re on nixos-unstable or release and do not have any custom commits on top of it.
Yeah, like I said, “Assuming you follow a ref which corresponds to a channel, I think this should always work.” If that assumption doesn’t hold, you either need to determine a “nearby” commit by whatever means is appropriate for how you consume nixpkgs and adapt this system to that, or you need to generate programs.sqlite yourself.
So I’m curious whether a single official best practice to tie NIX_PATH to the system’s flake configuration has already emerged? Is it on the way to becoming default (or at least added to the “official” instructions on the wiki)?
Instead of using /etc/nixPath, you could of course also just set the NIX_PATH environment variable, but that would require closing terminals in order to pick up the new value, so the on-disk version is more flexible.
EDIT: just to clarify, doing this means that all your regular nix-* tools work as expected with flakes.