I want to use a specific version of Bash in my shell.nix to aid in consistent shell environment to execute some Bash scripts. But using, say, bashInteractive_5 in my shell.nix’s buildInputs[] does not help.
It appears that nix-shell does install the requested version of package, but once inside the nix-shell, I still get Bash version 4, which is installed in my profile.
Is there an easy way to achieve this? Eventually I want to share the shell.nix with others in my team, so that their work also depends on the packages in the shell.nix.
Here’s my shell.nix:
with import <nixpkgs> {};
stdenv.mkDerivation {
name = "some_name";
buildInputs = [
coreutils
awscli
bashInteractive_5
];
}
This is ironic! This is the exact problem Nix is supposed to be solving. “Works on my machine” should not be in the vocabulary of the Nix users. From NixOS explore website:
You will no longer have to hear: But it works on my machine!
I guess nix-shell is an oddity rather than the norm.
I also find it troubling that nix-shell sources user’s ~/.bashrc and host machine’s /etc/bashrc, even in --pure mode. from nix-shell --help:
–pure … Note that ~/.bashrc and (depending on your Bash installation) /etc/bashrc are still sourced, so any variables set there will affect the interactive shell.
This behaviour is sure to cause “works on my machine” syndrome despite using Nix package manager.
I guess nix-shell is the wrong tool to do what I am trying to do. I would love to hear if there’s an alternative that works better than nix-shell, with respect to providing a clean, consistent, and reproducible development environment.
As I understand it, nix-shell is a tool built for working on Nix packages–not a tool built to create a hermetic bash5 execution environment for your scripts. For the same reasons it is useful for working on packages, it happens to be decent at building dev environments.
Because the tool is built to provide an interactive environment for humans to work on Nix packages (and not for you to run your bash5 scripts), it has helpful defaults like:
using the same bash that builds will use
providing a human-friendly version of the build environment
continuity with the user’s local development environment
It may or may not be a helpful way to run your scripts–but, like most tools, you may have to do a little extra work to use them for things they weren’t built for.
There isn’t enough detail here to give you strong recommendations, but some approaches that you might find fruitful:
If you really want newer bash everywhere, you can override it. I have something like bashInteractive = super.bashInteractive_5; and it hasn’t caused me much trouble that I can recall.
Using nix-shell as a shebang enables you to specify an interpreter and packages, but keep the script itself somewhere in ~/
Use shell.nix as you’re doing, but use the env to inject the bash you want, and the shellHook to assert whatever control you need over the environment inside.
“build” the scripts as a package and put them in the store, with the specific bash you want as their shebang, and either add them to your system/user packages, or add them to your shell.nix.
So I looked at the code of nix-shell and tried to reverse-engineer it and see how I could make it behave as I intend to use it. And the following is what I came up with. The hack uses nix’s feature shellHook and an additional file named rm; both listed below.
# cat shell.nix
with import <nixpkgs> {};
stdenv.mkDerivation {
name = "some_name";
buildInputs = [
which
bashInteractive_5
];
shellHook = ''
# Strip the first element from $PATH. This component was prepended by nix-shell
# to make sure the bash that it prefers gets used inside nix-shell environment
# as well.
export PATH="$(echo "$PATH" | cut -d : -f 2-)"
# Now invoke first bash found in $PATH. Use --norc to prevent invoking user's ~/.bashrc
exec env PS1='$ ' bash --norc
# Any code after the exec command above will not be executed
'';
}
@toraritte, I seem to be using the latest version of nix-shell, but my ~/.bashrc is still being invoked. So I did some digging and found that it’s because /etc/bashrc is being invoked, and that in turn, at least on my macOS, invokes my user-bashrc.
I presume nix-shell uses --norc flag on the bash command to ensure purity, but that does not prevent it from invoking system-wide bashrc located at /etc.
Note that this bahavior of Bash is expected, since the man page of bash says this.
--norc Do not read and execute the personal initialization file ~/.bashrc if the shell is interactive. This option is on
by default if the shell is invoked as sh.
@toraritte, I dug a bit further and it seems like that that commit you mention has made it to the master branch, but has never been released to public; none of the Git tags in the Nix repo. contain that commit.
$ git tag --contains 65f6d5db6f5ef2724a3dc03e1773c510123287f1
<empty response>
The last release from master, 2.3, was released on Sept 4, 2019 in 22d4ea7a989d26b86fc27706dfea0abd2fb52c52. Since we’re still in the 2.3.x series, there’s quite a lot of unreleased work in master.
You may be able to use the nixUnstable instead (assuming nothing else it includes is unacceptable…)
@abathur, the nix-shell I’m using is version 2.3.11, tagged on 2021/05/14, so I guess I’m using unstable already!? If that’s not the case, can you please explain how one would go about using nixUnstable; I’m using Nix on macOS.
Note: I’m speaking generally and am not intimately familiar with Nix’s maintenance/release practices.
No, you’re using a maintenance release in the 2.3.x (stable) release series, which branched off from master in Sept. 2019. The 2.3.x series continues to get some fixes while work towards the next stable release series continues in master. (2.3.x may continue to receive fixes even after the next stable release branches off from master).
It is grossly-simplified, but maybe a graph makes this clearer:
In nixpkgs, the nix attr is ~roughly the latest stable Nix release, but there is also a nixUnstable attr which is occasionally updated to a recent unreleased commit in the master branch.
I’m not really sure (I haven’t looked into doing this myself) but it’ll depend on how you’re managing your user/system packages in the first place (i.e., invoking nix-env, or nix-darwin/home-manager). It’s probably discussed in most getting-started-with-nix-flakes docs/tutorials. You may also be able to find good examples with a github code search.
This is the exact problem Nix is supposed to be solving. “Works on my machine” should not be in the vocabulary of the Nix users. From 