Devbox shell PATH should take precedence over existing binaries about devbox HOT 3 CLOSED

TLDR: There's potential interference from tools like asdf because it runs after devbox to set the shims.

I had the package issue here, but using ArchLinux. Using the ArchLinux wiki entry, I was able to overcome the Package not found.

In my case, adding a channel and updating it first was necessary. https://wiki.archlinux.org/title/Nix

But now devbox shell was indeed stuck for a while, like 10 minutes, with no feedback at all except 10% CPU usage and spinning fans on my laptop and some network connections downloading from nixos.org. Then started copying lots of nix packages.

After that it's indeed opening the shell, but it's using your shell, so asdf interferes with which binary will really run.

In my case, I was testing elixir. After devbox shell you need to asdf global elixir system so it uses the "system" elixir instead of the asdf chosen one. Then elixir complained about the locale not being properly set (something that the "real" elixir version from my system or asdf installed ones don't complain.

On top of that, which is not useful because asdf keeps pointing to the shim.

I'm only certain that the elixir version running is the nix one because you can check with htop that erlang is running from /nix/store.

So there's a lot of interference between asdf (potentially rbenv, nodenv, etc, too) and devbox shell.

There are too many layers to make confusion here. For instance, when I check locale from my shell it's indeed showing en_US.UTF-8 (my "real" shell), but when I run the iex (similar to ipython or irb), I see that the locale is not really UTF8. This is potentially another issue for my code, since now I need to find how to fix the locale inside the nix env, not my real env.

from devbox.

Looking at this in more detail. I think the shell did start on the first try, but there's "interferance" from asdf as @rdlu is suggesting. Basically, I think the asdf path is taking precedence over the devbox path – I'm going to see if we can ensure the PATH precedence is set up correctly whenever you call devbox shell

from devbox.

+1 I have the same issue with pyenv.

% devbox add python39
% devbox shell
Installing nix packages. This may take a while...
Starting a devbox shell...
% which python
/Users/haoguan/.pyenv/shims/python
% python -V
Python 3.10.0
% pyenv shell system
% python -V
Python 3.9.13

from devbox.