Parse `.python-version` file when `python-version` argument is not passed to action

[TomBurdge]

Use Case/Reproduce guide

• pyproject.toml specifies requires-python = ">=3.12".

• .python-version in repo root is 3.14 (or any compatible with requires-python field, I don't think it matters).

• Result of uv python find on your github action version running is 3.11 (we are running github action with docker image version 2.33.1.0 which appears to default to python 3.11).

• python-version argument to the action is not set.

• Probably not relevant: my project uses uv workspaces.

Outcome

• Setup action succeeds.
• Next step which uses uv after setup fails:

Using CPython 3.11.15
error: The requested interpreter resolved to Python 3.11.15, which is incompatible with the project's Python requirement: `>=3.12`.
The following `requires-python` declarations do not permit this version:
[redacted: my packages]

Proposal: Enhancement

• I could just resolve this by setting python-version. I don't want to do this - I am maintaining a compound reusable action which runs this step, along with plenty of others, in CI. As well as not wanting to expose arguments to end users, they have already created a .python-version file .
• Since passing the python-version can already resolve this, this should be considered an enhancement and not a bug.
• I would like to add in the action: capability to look for the .python-version file when python-version is not set. Use the .python-version found if the file exists, but revert to default behaviour (use uv python find) if it is not found. As part of this, it might be essential to check if the .python-version file conflicts with the requires semver in the pyproject.toml.

Would you consider this contribution? Thanks!

[eifinger]

Hi can you please share the whole workflow or at least the whole config of astral-sh/setup-uv and the whole command that throws the error.
Normally this has nothing to do with this action but is handled by uv itself.

The python-version input only sets the environment variable UV_PYTHON for the rest of the workflow and can be used to override .python-version for e.g. test matrixes.

The behavior you are describing looks like you configured uv to ignore managed python versions.