-
Notifications
You must be signed in to change notification settings - Fork 809
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 fails to find python in non-venv install on Windows #1779
Comments
Interesting, this is the same error I was getting in #1639 (cc. @MichaReiser) |
Have you created and activated a virtual environment? My and Micha's conclusion from debugging #1639 was that it's not possible on Windows (yet) to use the "trick" where you pretend a virtual environment has been created and activated by doing the (Edit: it looks like you are indeed doing the Unix-only "trick": https://github.com/tox-dev/tox-uv/blob/a93e37e98a012d07d6ac151e097c444a77d15b0a/.github/workflows/check.yml#L43) |
I outlined a cross-platform way of using |
Yeah, I can do that, but sounds more like a workaround than a solution for the underlying problem 👍 |
Oh of course. Longer-term we want to have first-class support for GitHub Actions, which I think will probably include something like #1526. We absolutely agree the current situation is far from ideal :) |
I ran into this error when trying to run pytest installed with uv from a pre existing conda environment. |
The main issue here is that @jenshnielsen #1803 might help with your issue, depending on the layout of the |
I wonder of this is related to the same issue I am having with embedded versions of Python: |
Is a solution for this in the works? I'm preparing an internal talk on UV for users that use windows and keen to know what they should expect. |
We're planning to solve this as part of #1526 The recommended local workflow is to use a venv instead of installing dependencies globally. |
Yup I'm on it. |
…erpreters (#2000) ## Summary This PR adds a `--python` flag that allows users to provide a specific Python interpreter into which `uv` should install packages. This would replace the `VIRTUAL_ENV=` workaround that folks have been using to install into arbitrary, system environments, while _also_ actually being correct for installing into non-virtual environments, where the bin and site-packages paths can differ. The approach taken here is to use `sysconfig.get_paths()` to get the correct paths from the interpreter, and then use those for determining the `bin` and `site-packages` directories, rather than constructing them based on hard-coded expectations for each platform. Closes #1396. Closes #1779. Closes #1988. ## Test Plan - Verified that, on my Windows machine, I was able to install `requests` into a global environment with: `cargo run pip install requests --python 'C:\\Users\\crmarsh\\AppData\\Local\\Programs\\Python\\Python3.12\\python.exe`, then `python` and `import requests`. - Verified that, on macOS, I was able to install `requests` into a global environment installed via Homebrew with: `cargo run pip install requests --python $(which python3.8)`.
When trying to run the tool on Windows, I get this rust like stack trace:
See https://github.com/tox-dev/tox-uv/actions/runs/7978647392/job/21784221224?pr=19
I'm using uv find_uv_bin...
The text was updated successfully, but these errors were encountered: