I use it like this:
$ nix-shell -I nixpkgs=channel:nixos-21.05 -p git --run "git --version"
git version 2.31.1
$ nix-shell -I nixpkgs=channel:nixos-unstable -p git --run "git --version"
git version 2.33.0
4 Likes
I’m gonna have to disagree. For flake based systems, it’s actually pretty nice to set the Nix path via nix.nixPath = [ "nixpkgs=${self.inputs.nixpkgs}" ];, as this actually solves the previous issue with the NIX_PATH being highly variable. Now instead, it is pinned, so that flake and non-flake commands both use the same nixpkgs by default (assuming you also set nix.registry.nixpkgs.flake = self.inputs.nixpkgs). I actually think that’s an improvement.
As for a situation where you may want to use a specific channel with a stable command, the answer given above by @hmenke is more than sifficient.
My feedback here stems specifically from loving flakes and finding them the superior option and user experience in every way.
Changing nix run, as a (subtly) marked experimental feature, that has been a widely-openly-known altered command? ok.
But it seems like the obvious choice to have just left nix-shell alone. My sympathies to OP of course but I’d basically not care about this if there was a 100% compatible nix-shell command to offer.
I want to choose my words politely. There are certain people who are not into flakes. Some of those reasons relate to how it has been introduced. I am much more sympathetic to those concerns (and larger concerns they might elicit) after seeing this.
I also worry about how this would go over if discussed in non-Nix communities. Not everyone else has had a chance to fall in love with flakes, on top of not everyone being familiar with nix tooling, plus any confusion already coming from the actual semantics changes around nix-shell/nix shell/nix run… it’s a lot. Can we just not add to it?
I really want flakes to succeed and be something that is safe and obvious to promote widely. This feels like a decent bit of friction and I… just think about being OP and finding out that nix run broke, there’s no backward compat shell equivalent and it’s all basically because of a non-RFC’d experimental feature called “flakes”? I feel bad for the marketing team.
(I’ve editted this a few times but I gotta stop. I hope it comes across that my words come from a place of love for Nix and the community and hopes for world derivation-ifying.)
7 Likes
So, here’s my issue:
nix develop .#legacy
[cole@raisin:~/code/nixcfg]$ nix --version
nix (Nix) 2.3.16
[cole@raisin:~/code/nixcfg]$ nix-channel --list
warning: unknown setting 'experimental-features'
nixos-2105 https://nixos.org/channels/nixos-21.05
nixos-unstable https://nixos.org/channels/nixos-unstable
[cole@raisin:~/code/nixcfg]$ nix-shell -I nixpkgs=channel:nixos-2105 -p git --run "git --vers
ion"
warning: unknown setting 'experimental-features'
warning: Nix search path entry 'channel:nixos-2105' cannot be downloaded, ignoring
error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I), at (string):1:13
[cole@raisin:~/code/nixcfg]$ nix-shell -I nixpkgs=nixos-2105 -p git --run "git --version"
warning: unknown setting 'experimental-features'
warning: Nix search path entry 'nixos-2105' does not exist, ignoring
error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I), at (string):1:13
[cole@raisin:~/code/nixcfg]$ nix-shell -I nixpkgs=nixos-^C05 -p git --run "git --version"
I am a bit frustrated and surprised I didn’t notice this earlier - but I’ve been insulated by using:
- nix-shell shell.nix
- shell.nix → flakes-compat
Imagine Continuous Integration users where they are subject to whatever Nix version is provided for them. Sure, you can workaround, workraround, but again, I have to reiterate how unfortunate it is to bundle such goodness with so much user hostility - this will break users, even users that weren’t relying on experimental nix run. (Unless I’m still missing something :/)
1 Like
Can you try -I nixpkgs=channel:nixos-21.05?
The nixpkgs=channel:nixos-2105 does not mean to use the nixos-2105 channel as it is defined on the system, it does mean to use the nixos-2105 channel from https://channels.nixos.org/$channelName.
As you can see the error already suggests that this download does not succeed. What you want is probably '<nixos-2105>', and it worked this way since I can remember and have used that command… Eg: nix-shell '<nixos-2105>' -p hello
1 Like
At least on Nix 2.4 RC1 (maybe on earlier Nix, idk), nix-shell -p ignores that path argument '<nixos-2105>'. It gives you whatever nixpkgs points to in NIX_PATH regardless.
nix-shell -A honors that argument, though.
I’m still a bit confused? What exactly broke in nix-shell? I haven’t noticed any such breakage, but I only use it sparingly. From what I understand, it still reads from NIX_PATH, and on NixOS at least, the default value for nix.nixPath still points to places where nix-channel would target?
What am I missing?
2 Likes
Thanks for the feedback! I’ve added some concrete examples to the release notes on how to update uses of nix run and nixpkgs.<package>: 2.4 release notes: Add some migration notes · NixOS/nix@9c6ac9e · GitHub
At some point we had a backward compatibility hack in 2.4 to support nixpkgs.<package>, but I removed it. It would probably be a good idea to make the error message more informative…
9 Likes
guix has just introduced a new top-level command to get the functionality they want without having to worry about backwards compatibility. I assume it’s to solve similar problems. (It’s called guix shell, ironically, but if we go this way we could choose a new name!)
The old
nixcommand was never stable.
I’ve tried my best to square this sentiment. But I just can’t. When we got rid of nix-repl, we pushed all users to nix repl. The REPL is fundamental to using Nix effectively. It’s just double-speak to say nix is experimental, because in practice, it was forced on every user.
What I think is more honest would be to say that nix is stable, but some of the subcommands aren’t.
Instead, what we have now is an ecosystem that is trying to push people to use experimental features, like flakes, but then when there’s problems just saying “but it’s experimental, so be ready for breaks.”
I’m okay with Nix being progressive and moving forward. But we need a better sense of stability, so people don’t feel pushed around.
I wish we had a tutorial that clearly explained to users how to do all the things they need to do with non-experimental features. I’d like to see that tutorial explain how to get around Nix without using a REPL. We could have seen these problems earlier. Things like tutorials highlight not only ergonomic issues, but critical missing features, as well as inconsistencies in tooling.
We should use documentation to drive design, rather than writing the documentation after-the-fact.
12 Likes
What about nix search?
I tried nix search -f '<nixpkgs>' sqlite but it does not work the way I was expecting.