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

uv under Win11 WSL-ubuntu sees wrong (win) python references #12185

Open
krstp opened this issue Mar 15, 2025 · 0 comments
Open

uv under Win11 WSL-ubuntu sees wrong (win) python references #12185

krstp opened this issue Mar 15, 2025 · 0 comments

Comments

@krstp
Copy link

krstp commented Mar 15, 2025

Here is an interesting turn of things... in the past days I had to work with Win11 box... as unusable as Windows-box is, it made me install virtual Ubuntu shell via WSL...

Long story short, when installing uv under virtual shell, that by default runs bash changed to zsh, some strange reference base python thing happens that instead of seeing *nix python versions, it sees the underlying Win11 pythons that clearly make it unusable or with some gimmicks will allow Win11 layer pythons usage which is super inefficient.

The core issue was, whenever I tried to instantiate uv venv, uv would not find the right python references, uv simply could not see and recognize the *nix layer pythons!

What did came with a rescue was pyenv, that carries correct local zsh references. So running pyenv and then uv for pip sync etc works just fine.

This also shows the inner-works of core uv for python env instantiation.. such as it runs on diff python references than follow up commands, which makes sense. However, relying only on uv under WSL-ubuntu for venv was not finalizing with success, by ingesting windows python references ¯_(ツ)_/¯ or rather unable to even correctly ingest those producing an error, which also makes sense.

This just shows uv runs better natively. And yes I did reinstall uv under WSL, it would still find win11 references.

Also, atm, I just want to give context why combination of pyenv with uv might be better in such scenario, where pyenv-venv yields some more env stability. Also this is not the first time pyenv-venv comes to the rescue, I am mostly mac and *nix user, and whatever hurdles I was dealing with in those systems in local development, the virtual env layer with pyenv-venv came each time to the rescue - if you prefer blame it on early uv releases or just my user error, whichever suits better; atm I am unable to reference the issues from the past I had, but there were some.

Thank you for working on such wonderful tool as uv! It really makes our lives easier. o7

Originally posted by @krstp in #1495 (comment)

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

1 participant