uv
uv copied to clipboard
astral-sh
`uv run` doesn't think the current environment is compatible when it is [rye virtual package issue?]
uv 0.1.35
platform: linux (x86_64)
Problem: uv run always creates a new environment even if current should be compatible, in certain projects.
Hi, trying out uv run for https://github.com/bluss/pyproject-local-kernel purposes (it is a thing that uses "rye run python", "poetry run python", "pdm run python" etc as appropriate depending on configuration).
I know that uv run is not an official feature yet, still it's fun to try to see how it works.
How to Reproduce
- git clone -b 0.5.5 https://github.com/bluss/pyproject-local-kernel
- cd pyproject-local-kernel/tests/server-client/client
- Inspect pyproject.toml and requirements files to see they only depend on ipykernel and jinja2.
- uv venv --python 3.11.7 # it's the python I happened to use
- uv pip install -r requirements.lock
- uv run -v python
Expected: It uses the environment ./.venv in the current directory
Actual behaviour: DEBUG Using Python 3.11.7 environment at .uv/.tmpvVFPMZ/bin/python
Note: Using python 3.12.2 instead has the same result. Note: Using uv pip install -r pyproject.toml instead of the requirements.lock file has the same result. Note: If I remove the dependencies in the pyproject.toml and reinstall, it still fails. So it might be about the client "package" defined by the pyproject.toml itself? That might be the cause, according to rye this is not a package at all, because it's marked virtual and should not be installed. (I don't know how uv is supposed to know that or if there's a rye agnostic way to configure this..)
In general I wanted here that if there was a complete "rye sync"'ed environment, it should be used as is by uv run if possible.
Thanks for giving it a try. This seems weird, I'd imagined this would work. I'll look into this.
This seems to be fixed. Uv has developed a lot since then, anyway. In this particular case it doesn't use an emphemeral venv anymore, so that's good.