Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pyenv not being added to PATH in WSL if Pyenv-Win is on PATH #2026

Open
bbulkow opened this issue Aug 7, 2021 · 13 comments
Open

Pyenv not being added to PATH in WSL if Pyenv-Win is on PATH #2026

bbulkow opened this issue Aug 7, 2021 · 13 comments

Comments

@bbulkow
Copy link

bbulkow commented Aug 7, 2021

pyenv mysteriously not working on WSL after Win11 upgrade

I've been using Pyenv happily with WSL and WIN11 forever. Feels like forever. Years. I prefer WSL1 because it is 10x faster for what I use (long story), and I'm still on Ubuntu 18.04 for my WLS1 shell.

I install via the basic "pull and bash" mechanism. I do a clone of the git repo into the usual location in the home directory, execute the path elements to point there, then pyenv init, in my .bash_alises , which has always worked before.

Right around when I upgraded to Windows 11 - probably two weeks ago, when Win11 came through the beta channel (not alpha), I noticed my python version was python2 instead of python3.

Digging in, I see that pyenv is installed properly, still, but when I 'which python' I get '/usr/bin/python', even though I have exec'd the init so the shims should be installed. Either the shims are not getting installed or they are getting removed or overridden?

I've checked every obvious thing I can find, and it just seems like the shims don't install. I've also tried going to a fresh WSL2 install on U20.04. I've looked at the path --- virtualenv was in front, and I removed that.

If I had to guess, I would assume there's some dependancy on the uname, which probably changed. The current one is:
Linux SUPERFLY 4.4.0-22000-Microsoft #1-Microsoft Fri Jun 04 16:28:00 PST 2021 x86_64 x86_64 x86_64 GNU/Linux

I've looked through the various scripts that should install the shims and just don't see anything.

Halp? Next places to look?

Description

  • WSL1 Ubuntu 18.04 on Windows 11 preview (beta channel, not alpha)
  • OS Architecture - AMD64
  • Pyenv version: 2.0.4-5-gab1a9d29
  • Python version: all
  • GCC 10 (Ubuntu 10.3.0-1ubuntu118.041)
@native-api
Copy link
Member

Looks like shims are not on PATH.

If you've upgraded to Pyenv 2 from an earlier version -- did you add eval "$(pyenv init --path)" to the session's login shell's configuration as per the README?

@distobj
Copy link

distobj commented Aug 11, 2021

FWIW, I'm having these exact same symptoms on Linux Mint. Just started yesterday after I did an apt upgrade and rebooted. Existing envs are broken, as are newly created ones.

My .bashrc contains the command eval "$(pyenv init -)" instead of the one recommended there. I just changed it to use --path, and now everything's working again.

@native-api
Copy link
Member

@distobj You need to not change - to --path but rather add a --path line to login shell's configuration (while the - line should be in interactive shell's configuration).

If you rather replace it, you'll lose the shell function and all its benefits (completion and some subcommands).

@bbulkow
Copy link
Author

bbulkow commented Aug 15, 2021

Changing to --path worked. Adding --path worked. Closing.

What changed? I don't know. The install doc could use a little more commentary on - vs --path (appears to control whether the path is added, necessary when the init is sourced, which seems to be happening maybe in different distros?)

@TristynAlxander
Copy link

@native-api, I may not be reading it correctly, but your comment makes it seem like you don't need to set your shims in non-login shells, and I do not think that is correct. I agree that you need to run both eval "$(pyenv init --path)" and eval "$(pyenv init -)" to add both shims and convince features, per the Advanced Configuration, but I think you need to run them both or add the shims manually:

eval "$(pyenv init --path)"
eval "$(pyenv init -)"

Alternatively,

export PATH="$PYENV_ROOT/shims:$PATH" 
eval "$(pyenv init -)"

Of course there are exceptions depending on your shell. Typical systems have two start-up files: .profile and something like .bashrc, .tcshrc, or .zshrc. In bash, these do not run at the same time. This is a quirk of bash. Most shells have the .profile that runs on login (e.g. ssh requires a password) and the .__shrc that runs on interactive (i.e. you see the terminal). Thus, you'd expect on a interactive login shell (almost all login shells) that both would run. In bash, this does not happen. .bashrc does not run on login shells. Many people using bash set up their .profile to run .bashrc so as to correct this quirk.

In that context it makes sense that you'd only want to run eval "$(pyenv init -)" when you are setting up interactive shells since it sets up convince features, but you'll want to add the shims to your path regardless of everything else. You should probably be careful not to add your shims to your path twice but avoiding that depends on both shell and personal configuration (i.e. if your .profile runs .__shrc).

@native-api
Copy link
Member

you don't need to set your shims in non-login shells

A non-login shell is always a descendant of a login shell. So if you set up the PATH in the session's login shell, you don't need to do it again in non-login ones.

@andersrmr
Copy link

andersrmr commented Jan 2, 2023

i recently installed WSL in windows 11 and appear to be having a related problem. I'm trying to run vscode on top of WSL. My .profile and .bashrc are as follows:

export PYENV_ROOT="$HOME/git/.pyenv"
command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init --path)"
eval "$(pyenv init -)"

but i'm getting an error, repeating multiple times, as you can see:

/mnt/c/Users/myusername/.pyenv/pyenv-win/bin/pyenv: 3: cygpath: Permission denied
/mnt/c/Users/myusername/.pyenv/pyenv-win/bin/pyenv: 3: exec: cmd: Permission denied
/mnt/c/Users/myusername/.pyenv/pyenv-win/bin/pyenv: 3: cygpath: Permission denied
/mnt/c/Users/myusername/.pyenv/pyenv-win/bin/pyenv: 3: exec: cmd: Permission denied

Anyone know how to fix this? Separately, I have it working on the windows side with pyenv-win. Ultimately, I'd like to be able to use vs-code with my chosen version of python..

It's not clear to me that the PATH is being updated correctly. vscode and windows system environmental variables precede my user variables on PATH.

@native-api
Copy link
Member

@andersrmr Not relevant to Pyenv. We do not use cygpath.

@antoine-lombardo
Copy link

antoine-lombardo commented Mar 27, 2023

w how to fix this? Separately, I have it working on the windows side with pyenv-win. Ultimately, I'd like to be able to use vs-code with my chosen version of python..

It's not clear to me that the PATH is being updated correctly. vscode and windows system environmental variables precede my user variables o

I was getting the same error, I resolved it by modifying the .bashrc and .profile lines for these:

export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init - --path)"

This will make sure to add the pyenv root dir in the path even if it pyenv-win is detect on the host machine.

@looeee
Copy link

looeee commented Apr 16, 2024

For anyone else having this issue because pyenv-win is installed, see the comment here:

export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH" # instead of `command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"`
eval "$(pyenv init -)"

You may also need to change the last line to:

eval "$(pyenv init - --path)"

@native-api native-api changed the title pyenv mysteriously not working on WSL after Win11 upgrade Pyenv not being added to PATH in WSL if Pyenv-Win is on PATH Apr 16, 2024
@native-api
Copy link
Member

native-api commented Apr 16, 2024

Perhaps we can adjust the initialization code to work in the case when Pyenv-Win is on PATH.
Then we need to figure out how to detect that.


Alternatively -- and perhaps preferrably -- why does it even end up on PATH is WSL? I'm not familiar with WSL. AFAIK it's an Ubuntu VM with the host FS visible as a mount.

Why even add something from the host FS to PATH? Windows executables cannot run in the VM, can they? So what's the point?

@native-api native-api reopened this Apr 16, 2024
@Brandontam29
Copy link

You can run window commands like explorer.exe . in your wsl terminal because Window commands are mounted in /mnt/Users/

Why even add something from the host FS to PATH? Windows executables cannot run in the VM, can they? So what's the point?

@theangkko
Copy link

theangkko commented May 29, 2024

For anyone else having this issue because pyenv-win is installed, see the comment here:

export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH" # instead of `command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"`
eval "$(pyenv init -)"

You may also need to change the last line to:

eval "$(pyenv init - --path)"

With above reply, I cannot resolve my issue that is same with you ( pyenv-win in Window, pyenv in WSL2)

but refer to the article, https://stackoverflow.com/a/76483889/14103688
I succeed with below commands

export PYENV_ROOT="$HOME/.pyenv"
command -v pyenv >/dev/null || export PATH=""$PYENV_ROOT/bin:$PATH"

BIN_OLD="/mnt/c/Users/username/.pyenv/pyenv-win/bin"
BIN_NEW="$PYENV_ROOT/bin"
SHIMS_OLD="/mnt/c/Users/username/.pyenv/pyenv-win/shims"
SHIMS_NEW="$PYENV_ROOT/shims"
export PATH=echo $PATH | sed "s@$BIN_OLD@$BIN_NEW@" | sed "s@$SHIMS_OLD@$SHIMS_NEW@"
eval "$(pyenv init -)"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants