Use the shell you launched nix shell
and nix develop
from #464
Labels
No labels
Area/build-packaging
Area/cli
Area/evaluator
Area/fetching
Area/flakes
Area/language
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/store
bug
crash 💥
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
RFD
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
ux
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#464
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Is your feature request related to a problem? Please describe.
When running
nix shell
ornix develop
, the shell that's used is always bash, regardless of what shell you launched it from. You can use nix-your-shell to fix this, but it would be nice if it was built-in.Describe the solution you'd like
nix shell
andnix develop
should use the shell you launched them from (i.e.fish
)This is not trivial because you have to actually do the nix-your-shell thing which varies depending on the shell. Shell hooks and so on can define anything from functions to environment variables, in principle. Of course the average shell does a lot less, but it feels a little bit unintuitive to use a shell that will not work to actually "develop" a derivation when you run
nix develop
.I agree though that this is annoying behaviour and should have a built-in fix, but I don't see that it is always sound to apply it.
This is, more than anything, showing the tension between the "debug a derivation" use case of
nix develop
and the "provide a dedicated dev shell" use case.For what it's worth, I think that
nix shell
does not actually launch bash based on the testing I just did, but maybe I have configured something.nix-shell
will launch bash for the same reason asnix develop
.nix shell
already does this. From the docs:So if this doesn't work for you, I assume the
SHELL
variable isn't set up?When I run
nix shell
from zsh, it launches zsh. When I change theSHELL
variable, it launches the respective shell.As jade said,
nix develop
does not use the user's shell for a good reason. It is supposed to create a reproducible environment that guarantees the presence of certain commands as well as the executing shell.Yeah, making
nix develop
always use bash makes sense. One problem with the waynix shell
does it though. If yourSHELL
is set to bash, even though you use bash (because fish isn't posix compliant and can break things as a login shell), thennix shell
will still use bash. That's why I think it would be better to launch the shell that the command was called from.Hm, how does anything else that shoves you in a shell environment handle this? Querying the parent process is an incredibly wrong solution so that's out. I can tell you that neovim
:terminal
does just use$SHELL
for determining what to launch, which will have the exact problem you describe here, but you can just do whatever neovim things to alias this problem out of existence.However, I think it is a semi-footgun to make this into a config option, since
nix develop
would still bebash
.You know this is a good point, maybe we should consider widening this distinction? Debugging a derivation and having an environment suitable for general development both want the build inputs the derivation needs, but the former wants exact shell hooks while the latter often only really cares about environment variables.
The NixCpp team has struggled with this distinction for a long time and has recently taken the first step to allow for more different usecases here: https://github.com/NixOS/nix/pull/10807
Basically, the idea is to have separate
nix dev shell
andnix env shell
commands, and allow for extending thenix dev
andnix env
groups based on different usecases. Not saying that's the best direction to take, but it's a decent option.Is it? I just tried out poetry, and it did not care about me changing
$SHELL
, it always used the shell I'm actually launching it from. In their shell-detection routine they use a library called shellingham, which queries both ps and /proc for the current PID and tries to figure the shell out that way. Only if that fails will poetry fall back to$SHELL
.