Hi! When a uv pin in pyproject.toml carries a PEP 508 environment marker, setup-uv's version-detection scrapes the version string but does not strip the marker. It captures everything up to the marker's semicolon (the semicolon included) and then fails to match it against the version manifest.
Given an entry of this form under a [dependency-groups] table in my pyproject.toml:
test = [
"uv==0.11.20; sys_platform != 'emscripten'",
]setup-uv in CI logs the following:
Found version for uv in .../pyproject.toml: 0.11.20;
Getting available versions from https://raw.githubusercontent.com/astral-sh/versions/main/v1/uv.ndjson ...
##[error]No version found for 0.11.20;
The expected behaviour should be to strip the marker, i.e., everything from the first ; onward before parsing the version. Ideally, perhaps ideally recognising the environment marker too, by evaluating it against the runner's environment? At a minimum, it should not be treated as part of the version string.
For now, I have a workaround, as I can set the version: input for the action and pin it there, so as to skip the version detection from the repository's files.
I noticed this in zarr-developers/zarr-python#1903, where the CI started failing: https://github.com/zarr-developers/zarr-python/actions/runs/27768428985/job/82161430615?pr=1903 (and other PR workflows as well, besides this one).
Hi! When a uv pin in pyproject.toml carries a PEP 508 environment marker, setup-uv's version-detection scrapes the version string but does not strip the marker. It captures everything up to the marker's semicolon (the semicolon included) and then fails to match it against the version manifest.
Given an entry of this form under a [dependency-groups] table in my pyproject.toml:
setup-uv in CI logs the following:
The expected behaviour should be to strip the marker, i.e., everything from the first ; onward before parsing the version. Ideally, perhaps ideally recognising the environment marker too, by evaluating it against the runner's environment? At a minimum, it should not be treated as part of the version string.
For now, I have a workaround, as I can set the version: input for the action and pin it there, so as to skip the version detection from the repository's files.
I noticed this in zarr-developers/zarr-python#1903, where the CI started failing: https://github.com/zarr-developers/zarr-python/actions/runs/27768428985/job/82161430615?pr=1903 (and other PR workflows as well, besides this one).