It would be nice to support more than just bash. I wonder if zsh has something like rcfile?

Unfortunately not:

https://stackoverflow.com/questions/2727172/how-to-load-different-zshrc-file-via-commandline-option

also all the phases contain bash-specific code in nixpkgs.

oops.

I wonder if we should not use the builder attribute so that if your builder is python, it would start a python shell.

We would need a new interface that says that the builder can accept a --shell argument I think, so that it can load all the libraries (or stdenv)

We can't use the builder attribute because that would give us a non-interactive bash.

Maybe we should copy the nix-shell behavior, which is to use bashInteractive from nixpkgs. The modern variant would be to fetch nixpkgs#bashInteractive. This ensures that things work on macOS (where the system bash is ancient) and that nested shells work properly.

Maybe we should copy the nix-shell behavior, which is to use bashInteractive from nixpkgs. The modern variant would be to fetch nixpkgs#bashInteractive. This ensures that things work on macOS (where the system bash is ancient) and that nested shells work properly.

It's quite common to pin nixpkgs using builtins.fetchTarball in the code and completely ignore NIX_PATH. So this might risk of loading a version of bash coming from another channel. I guess once flakes is finished it will be easier to unify everything under one roof.

@zimbatm Ideally we would use the nixpkgs flake from the inputs of the top-level flake.

BTW, commit 9b9de3a makes it feasible to support other shells since it separately extracts environment variables and bash functions.

@zimbatm

So this might risk of loading a version of bash coming from another channel

Why is this an issue for an interactive shell? I would imagine that it's better to do this than to use bash from path in most cases. Am I missing something?

Closing now that #3565 is merged