Strange interaction between load_nvm and pyenv

[eric-g-97477]

Operating system and version:

nvm debug output:

```sh nvm --version: v0.39.1 $TERM_PROGRAM: iTerm.app $SHELL: /usr/local/bin/fish $SHLVL: 2 whoami: 'eric' ${HOME}: /Users/eric ${NVM_DIR}: '${HOME}/.nvm' ${PATH}: ${NVM_DIR}/versions/node/v16.15.1/bin:${HOME}/.pyenv/versions/3.10.4/bin:/usr/local/Cellar/pyenv/2.3.3/libexec:/usr/local/Cellar/pyenv/2.3.3/plugins/python-build/bin:${HOME}/.pyenv/shims:${HOME}/.pyenv/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin $PREFIX: '' ${NPM_CONFIG_PREFIX}: '' $NVM_NODEJS_ORG_MIRROR: '' $NVM_IOJS_ORG_MIRROR: '' shell version: 'fish, version 3.5.1' uname -a: 'Darwin 21.6.0 Darwin Kernel Version 21.6.0: Sat Jun 18 17:07:25 PDT 2022; root:xnu-8020.140.41~1/RELEASE_X86_64 x86_64' checksum binary: 'shasum' OS version: macOS 12.5 21G72 curl: /usr/bin/curl, curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.45.1 wget: /usr/local/bin/wget, GNU Wget 1.21.3 built on darwin21.3.0. sed: /usr/bin/sed cut: /usr/bin/cut basename: /usr/bin/basename rm: /bin/rm mkdir: /bin/mkdir xargs: /usr/bin/xargs git: /usr/local/bin/git, git version 2.37.2 grep: /usr/bin/grep, grep (BSD grep, GNU compatible) 2.6.0-FreeBSD awk: /usr/bin/awk, awk version 20200816 nvm current: v16.15.1 which node: ${NVM_DIR}/versions/node/v16.15.1/bin/node which iojs: which npm: ${NVM_DIR}/versions/node/v16.15.1/bin/npm npm config get prefix: ${NVM_DIR}/versions/node/v16.15.1 npm root -g: npm WARN config global `--global`, `--local` are deprecated. Use `--location=global` instead. ${NVM_DIR}/versions/node/v16.15.1/lib/node_modules ```

nvm ls output:

```sh ~ [42]$ nvm ls 10:09:12 v10.16.0 v10.24.1 v12.18.1 v12.22.10 v15.0.1 v16.14.2 -> v16.15.1 default -> lts/* (-> v16.15.1) iojs -> N/A (default) unstable -> N/A (default) node -> stable (-> v16.15.1) (default) stable -> 16.15 (-> v16.15.1) (default) lts/* -> lts/gallium (-> v16.15.1) lts/argon -> v4.9.1 (-> N/A) lts/boron -> v6.17.1 (-> N/A) lts/carbon -> v8.17.0 (-> N/A) lts/dubnium -> v10.24.1 lts/erbium -> v12.22.12 (-> N/A) lts/fermium -> v14.19.3 (-> N/A) lts/gallium -> v16.15.1 ```

How did you install nvm?

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

What steps did you perform?

My config.fish is:

if status is-interactive
    set -Ux PYENV_ROOT $HOME/.pyenv
    set -U fish_user_paths $PYENV_ROOT/bin $fish_user_paths
    pyenv init - | source
end

set -x LESS -eFRX

load_nvm

function ll
    ls -la
end

What happened?

When I echo $PATH, I see:

(some parts removed for simplicity)

/Users/eric.gorr/.pyenv/versions/3.10.4/bin /Users/eric.gorr/.pyenv/shims

The key thing to note is that load_nvm placed /Users/eric.gorr/.pyenv/versions/3.10.4/bin before pyenv's shims path. This prevents the proper operation of pyenv and it's ability to control what version of python is being used from working.

What did you expect to happen?

I do not expect load_nvm to install a path related to python.

Is there anything in any of your profile files that modifies the PATH?

Yes. I have the pyenv init - | source in my config.fish file.

If I modify my config.fish file to be:

load_nvm

if status is-interactive
    set -Ux PYENV_ROOT $HOME/.pyenv
    set -U fish_user_paths $PYENV_ROOT/bin $fish_user_paths
    pyenv init - | source
    echo "pyenv setup complete" $PATH
end

set -x LESS -eFRX

function ll
    ls -la
end

If I place load_nvm before the pyenv setup, then I do not see /Users/eric.gorr/.pyenv/versions/3.10.4/bin appear in $PATH.

I can then use pyenv normally.

load_nvm should be able to detect that python is already in the path via the pyenv shims and not insert a path on its own.

Or, is there a reason why this cannot happen?

Or, am I doing something wrong?

[ljharb]

I’m a bit confused. nvm doesn’t support fish, and load_nvm isn’t part of nvm itself (altho it might come from the readme)

[eric-g-97477]

Yes, I found load_nvm in the readme and assumed that if it was in the readme, it was supported -- at least to some extent.

I did trace the addition of /Users/eric.gorr/.pyenv/versions/3.10.4/bin into the PATH to when load_nvm executed:

nvm use default

I have no idea why that part of nvm would be doing that insert...seems weird.