astral-sh
Feature Request: Expose python and venv discovery as a machine interpretable uv subcommand
Many tools in the python development process could benefit from a consistent way of resolving the current project's python executable and virtual env. Since uv already has documented logic for python discovery it would be nice if we could just build off of this mechanism.
One example is how pyright tries to do its own python discovery but in many cases doesn't work properly. The way pyright actually works when it's invoked via pylance in vscode is closer to the following invocation pyright --pythonpath $ABS_PATH_TO_PYTHON --project $ABS_PATH_TO_PROJECT_ROOT see this discussion on how to improve the python experience in Zed.
VSCode and PyCharm have similar issues where the user usually has to go hunt for the path to the python interpreter. Poetry does a similar python discovery, if you've installed poetry via pipx this means you already have an active venv so you find yourself needed to do pyenv ... && poetry env use $(which python) to make sure it doesn't pick the pipx base python install (often either system python or homebrew managed python rather than the pyenv managed version you actually want).
I'm sure there are details to think through, but a first proposal might be something like the following:
uv which python [PATH(default=PWD)]
where the path could be a PROJECT_ROOT (containing a pyproject.toml or some other marker) or any child path of the project root. I'm assuming ruff could also share some of this project root and python language version inference logic
Interesting idea! I'm not sure how we'd want to expose this but I feel the pain of finding versions.
See also #2386 which defines robust logic we want to implement for interpreter discovery.
