Support pyenv if it is installed in a non-default directory

[wedeluxe]

Environment data

• VS Code version: 1.25.0
• Extension version (available under the Extensions sidebar): 2018.6.0
• OS and version: Arch Linux (up-to-date)
• Python version (& distribution if applicable, e.g. Anaconda): 3.6.6 (pyenv)
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A

Actual behavior

Assuming pyenv is installed in a non-default dir.
Python interpreters installed with pyenv are not listed when running the "Python: Select Interpreter" command.

Expected behavior

Assuming pyenv is installed in a non-default dir.
Python interpreters installed with pyenv are listed when running the "Python: Select Interpreter" command.

Steps to reproduce:

1. Properly install pyenv to a non-default location, i.e. a directory different from ~/.pyenv.
   This includes setting the PYENV_ROOT environment variable to the chosen directory.
2. Install one or more Python versions using pyenv. Example: pyenv install 3.6.6.
3. Within vscode run the "Python: Select Interpreter" command.
4. All Python versions/interpreters installed in step (2) are not included in the list shown.

Workaround

Create a symlink in the home directory pointing to the actual pyenv dir.
ln -s /the/actual/path/to/pyenv ~/.pyenv

After doing so, all Python versions installed with pyenv are listed in the select interpreter area.

Proposed Solution

• Do not hardcode the pyenv root dir to ~/.pyenv.
• Read its location from the PYENV_ROOT environment variable.
• (Maybe) use ~/.pyenv as fallback value.

[d3r3kk]

Hi @wedeluxe, thanks for taking the time to submit the issue!

I am running on Ubuntu 18.04 at the moment, and use pyenv heavily in the development of our extension. When I choose the interpreter I can see all installed versions available via my pyenv setup:

Do you have the following in your .bash_profile (or alt for your system):

export PYENV_ROOT=/opt/python/pyenv
export PATH="$PYENV_ROOT/bin:$PATH"
if command -v pyenv 1>/dev/null 2>&1; then
  eval "$(pyenv init -)"
fi

...as mentioned in the pyenv setup item (3) here?

[wedeluxe]

@d3r3kk
Yes, it's all in there. From my .bashrc file:

export PYENV_ROOT="/wdlx/machines/pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
if command -v pyenv 1>/dev/null 2>&1; then
    eval "$(pyenv init -)"
fi

I can reproduce this behavior:

• Close vscode.
• Deactivate/remove the symlink (see workaround).
• Start vscode.

---> All interpreters installed with pyenv are not listed.

• Close vscode.
• Activate/create the symlink (see workaround).
• Start vscode.

---> All interpreters installed with pyenv are back and listed.

Tried that again a couple of minutes ago

[d3r3kk]

Great, thanks for getting back to me. Since I can see the pyenv versions and I also install my pyenv environment to a non-standard location (/opt/python/pyenv), I'll need to figure out how my environment is getting found. Let me test around a bit when I get time today and get back to you.

[wedeluxe]

Additional note (I forgot to mention before):

When the symlink is active/created and the pyenv interpreters are listed, they are listed with the symlink path

/home/matt/.pyenv/versions/3.6.6/bin/python

and not with the true/actual path

/wdlx/machines/pyenv/versions/3.6.6/bin/python

Maybe this is of any help.

[d3r3kk]

Thanks! Yes that may have something to do with it, I'll have to see. Mine show up in their installed paths, so we definitely have some differences I can investigate.

[brettcannon]

This could be an issue of the environment variables being specified in .bashrc and not in e.g. .bash_profile.

[d3r3kk]

Yes, @wedeluxe could you try putting that in your .bash_profile and trying again?

From here, I can't quite sort out if .bashrc is sourced from .bash_profile or not in Arch Linux. Seems it depends...

[wedeluxe]

I did a lot of testing.

What I did

Moved the lines

export PYENV_ROOT="/wdlx/machines/pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
if command -v pyenv 1>/dev/null 2>&1; then
    eval "$(pyenv init -)"
fi

from ~/.bashrc into ~/.bash_profile.

Result

But that has no effect on the issue described in the initial posting.
The behavior I talked about in the comment above (interpreters are listed depending on the existence of the symlink) can still be reproduced.

Additionally other things get worse.
Pyenv is not properly initialized in GNOME3 terminal windows. I had to check Preferences > Command > Run command as a login shell to repair this.
Pyenv is not properly initialized in vscode bash terminals. Can't find a way to repair this.

Finally

Regarding these problems, I went back to the previous setup, i.e. moved the lines back into ~/.bashrc.

To answer your implicit question: ~/.bashrc is sourced from ~/.bash_profile on my system. There also is a slight indication to this on the page you linked to. Somewhat hidden in the table it says:

The skeleton file /etc/skel/.bash_profile also sources ~/.bashrc

[d3r3kk]

Thanks for going to all that trouble! I appreciate it. I wasn't 100% confident that .bashrc was being sourced from .bash_profile in your user directory - and I wasn't clear on bash using the skel version of .bash_profile for each interactive shell... sigh.

Ok, I will have to dig in and see what I can come up with on my end. Thanks for helping out!

[wedeluxe]

Oh, I'm not quite sure if this is a misunderstanding.

Bash does not use the skel version of bash_profile.
Files in the /etc/skel directory are used as default initial content when a new user's home directory is created on a system.
Thus the line I cited is just saying: By default ~/.bash_profile sources ~/.bashrc

[brettcannon]

@wedeluxe are you running VS Code from the shell or from a shortcut? By suspicion is if you have to tell GNOME to source your config files then if you're launching from a shortcut it isn't using a shell environment that is sourcing your configs either and that's why VS Code isn't seeing PYENV_ROOT.

[brettcannon]

Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on then we will be happy to re-open this issue to pick up where we left off.