Skip to content

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

Closed
Closed
Support pyenv if it is installed in a non-default directory#2142
Labels
feature-requestRequest for new features or functionalityinfo-neededIssue requires more information from poster

Description

@wedeluxe
wedeluxe (wedeluxe)
opened on Jul 12, 2018

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.

Activity

  1. Derek Keeler (d3r3kk)
    added
    feature-requestRequest for new features or functionality
    info-neededIssue requires more information from poster
    feature-interpreter
    on Jul 12, 2018

  2. d3r3kk commented on Jul 12, 2018

    @d3r3kk
    Derek Keeler (d3r3kk)
    on Jul 12, 2018

    Hi wedeluxe (@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:

    image

    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?

  3. wedeluxe commented on Jul 12, 2018

    @wedeluxe
    wedeluxe (wedeluxe)
    on Jul 12, 2018
    Author

    Derek Keeler (@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

  4. d3r3kk commented on Jul 12, 2018

    @d3r3kk
    Derek Keeler (d3r3kk)
    on Jul 12, 2018

    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.

  5. wedeluxe commented on Jul 12, 2018

    @wedeluxe
    wedeluxe (wedeluxe)
    on Jul 12, 2018
    Author

    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.

  6. d3r3kk commented on Jul 12, 2018

    @d3r3kk
    Derek Keeler (d3r3kk)
    on Jul 12, 2018

    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.

  7. brettcannon commented on Jul 12, 2018

    @brettcannon
    Brett Cannon (brettcannon)
    on Jul 12, 2018
    Member

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

  8. Brett Cannon (brettcannon)
    added
    needs verification
    and removed
    info-neededIssue requires more information from poster
    on Jul 12, 2018

  9. d3r3kk commented on Jul 12, 2018

    @d3r3kk
    Derek Keeler (d3r3kk)
    on Jul 12, 2018

    Yes, wedeluxe (@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...

  10. wedeluxe commented on Jul 13, 2018

    @wedeluxe
    wedeluxe (wedeluxe)
    on Jul 13, 2018
    Author

    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

  11. d3r3kk commented on Jul 13, 2018

    @d3r3kk
    Derek Keeler (d3r3kk)
    on Jul 13, 2018

    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!

  12. wedeluxe commented on Jul 13, 2018

    @wedeluxe
    wedeluxe (wedeluxe)
    on Jul 13, 2018
    Author

    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

  13. brettcannon commented on Jul 13, 2018

    @brettcannon
    Brett Cannon (brettcannon)
    on Jul 13, 2018
    Member

    wedeluxe (@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.

  14. Brett Cannon (brettcannon)
    added
    info-neededIssue requires more information from poster
    and removed
    needs verification
    on Aug 2, 2018

  15. brettcannon commented on Sep 27, 2018

    @brettcannon
    Brett Cannon (brettcannon)
    on Sep 27, 2018
    Member

    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.

  16. Brett Cannon (brettcannon)
    closed this as completedon Sep 27, 2018
  17. lock
    locked as resolved and limited conversation to collaborators on Oct 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature-requestRequest for new features or functionalityinfo-neededIssue requires more information from poster

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions