Validate that discovered interpreters meet the Python preference

[zanieb]

Closes #5144

e.g.

❯ cargo run -q -- sync --python-preference only-system
Using CPython 3.12.6 interpreter at: /opt/homebrew/opt/[email protected]/bin/python3.12
Removed virtual environment at: .venv
Creating virtual environment at: .venv
Resolved 9 packages in 14ms
Installed 8 packages in 9ms
 + anyio==4.6.0
 + certifi==2024.8.30
 + h11==0.14.0
 + httpcore==1.0.5
 + httpx==0.27.2
 + idna==3.10
 + ruff==0.6.7
 + sniffio==1.3.1
 
❯ cargo run -q -- sync --python-preference only-managed
Using CPython 3.12.1
Removed virtual environment at: .venv
Creating virtual environment at: .venv
Resolved 9 packages in 14ms
Installed 8 packages in 11ms
 + anyio==4.6.0
 + certifi==2024.8.30
 + h11==0.14.0
 + httpcore==1.0.5
 + httpx==0.27.2
 + idna==3.10
 + ruff==0.6.7
 + sniffio==1.3.1

[zanieb]

We should probably opt active virtual environments out of this?

[konstin]

We should probably opt active virtual environments out of this?

If i specifically pass --python-preference only-system i'd expect uv to invalidate the current venv and recreate, i sees this mismatch like requesting a different Python version than the currently active one. (Admittedly, this is a somewhat fringe problem)

[zanieb]

If i specifically pass --python-preference only-system i'd expect uv to invalidate the current venv and recreate,

But.. uv run outside a project and uv pip install can't just invalidate and recreate an environment — should they fail?

[konstin]

I think so

[konstin]

nit: This can be a method on PythonSource

[konstin]

How is VIRTUAL_ENV different here, doesn't that imply that I get different behavior depending on whether I activate the venv first and then uv run or whether I only use uv run, which is usually the same?

[zanieb]

VIRTUAL_ENV is set to the default virtual environment path (just by the test context)

This does imply you get different behavior based on whether the environment is active. I think that's correct though? With an active environment, it would be incorrect to ignore it (at most, we should warn), but when performing environment discovery, it makes sense to bypass environments that do not meet the preference.

[konstin]

If you have a project with requires-python = ">=3.11" and try a too old venv with

uv venv -p 3.9
uv run python --version

then uv will recreate the venv in a compatible version and you'll get e.g. Python 3.13.5. This is independent of whether the venv is activated or not. I'd be surprised if there was different behavior between the Python version and the Python source wrt to the when we invalidate.

More concretely, I'd expect both blocks to share the invalidation behavior:

uv run --python-preference only-system -p 3.10 python --version
uv run --python-preference only-system -p 3.11 python --version

uv run --python-preference only-system -p 3.10 python --version
uv run --python-preference managed -p 3.10 python --version

[zanieb]

Yeah this behavior differs outside of projects because:

1. Outside of a project, we can't "invalidate" and recreate a virtual environment.
2. Projects don't consider VIRTUAL_ENV at all by default

This is intended to avoid making the breaking change too disruptive. While I might agree with you that it's better to have a consistent behavior, I think it's too risky to change.

[zanieb]

To be clear, you're commenting on a test that is covering the behavior of uv run outside of a project. For project environments, we have the behavior you're looking for.

[konstin]

Oh, I see!

[konstin]

This branch seems to have a bad interaction with the minor version links for Python upgrades (CC @jtfmumm). Rerunning the last command recreates the venv in a loop on my machine

uv python uninstall --all --preview
uv init -p 3.10 foo
cd foo
uv run --preview --python-preference only-managed -p 3.10 python --version

Logs: https://gist.github.com/konstin/709fb6c4467fc607cfbea985f5ee8822

[zanieb]

That should be fixed by fbebb7a