Devbox shell PATH should take precedence over existing binaries

[methyl]

Hey!

Just been testing devbox and the experience so far is really smooth. I stumbled upon 3 things that confused me:

1. devbox add package failed with Package not found until I opened a new terminal. It's kind of documented, but maybe there is a way for a better error? Anyway, that's a nit.
2. devbox shell first run can take quite some time and there is no progress bar, but we already have First call to devbox shell can take a while #7
3. Which is this issue really about.

It seems the initial run of devbox shell does not spawn the shell, instead it exists once it completes package initialization. Here's the terminal log that shows the issue:

lucjansuski@MacBook-Pro-3 ~ % cd /tmp
lucjansuski@MacBook-Pro-3 /tmp % mkdir test
lucjansuski@MacBook-Pro-3 /tmp % cd test
lucjansuski@MacBook-Pro-3 test % devbox init
lucjansuski@MacBook-Pro-3 test % devbox add python
lucjansuski@MacBook-Pro-3 test % devbox shell
this path will be fetched (7.93 MiB download, 49.47 MiB unpacked):
  /nix/store/3j1bsklak6p752nhys18n0p9i3grq1bz-python-2.7.18
copying path '/nix/store/3j1bsklak6p752nhys18n0p9i3grq1bz-python-2.7.18' from 'https://cache.nixos.org'...
Starting a devbox shell...
lucjansuski@MacBook-Pro-3 test % which python
/Users/lucjansuski/.asdf/shims/python
lucjansuski@MacBook-Pro-3 test % devbox shell
Starting a devbox shell...
MacBook-Pro-3:test lucjansuski$ which python
/nix/store/3j1bsklak6p752nhys18n0p9i3grq1bz-python-2.7.18/bin/python
MacBook-Pro-3:test lucjansuski$

I'm on macOS Monterey 12.5.

[rdlu]

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.

[loreto]

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

[raptium]

+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