version-file does not respect uv.lock or dependency-groups

[inoa-jboliveira]

I wanted to not have to update my GHA every time I update uv, so I found this option:

    # Path to a file containing the version of uv to install (default: searches uv.toml then pyproject.toml)
    version-file: ""

I have uv setup on pyproject.toml as a

[dependency-groups]
uv = [
    "uv==0.8.17",
]

I also have

[tool.uv]
required-version = ">=0.5.21"

Therefore I do have uv locked in uv.lock.

What I don't get is why uv.lock is being ignored and also the dependency group.
The output from the task is

Found version for uv in /home/runner/_work/path/path/pyproject.toml: >=0.5.21
Found minimum version specifier, using latest version
Getting latest version from GitHub API...
manifest-file not provided, reading from local file.
manifest-file does not contain version 0.9.10, arch x86_64, platform unknown-linux-gnu. Falling back to GitHub releases.
Downloading uv from "https://github.com/astral-sh/uv/releases/download/0.9.10/uv-x86_64-unknown-linux-gnu.tar.gz" ...

Is there a way to specify that it uses the version locked? I cannot change required-version because it breaks perfectly good installations and it works as a bare minimum for other actions. Plus if I bump the required-version, the devs can't even update uv itself

[eifinger]

Hi, a few question to better understand your needs:

Do you have "uv==0.8.17" in your pyproject.toml just to control this action? Do you depend on uv in your code?
What is your requirement to not use the latest uv? Preventing possible breaking changes?

[inoa-jboliveira]

Hi @eifinger
I have some reasons for adding uv to the env itself, many related to having to change the workflow of hundreds of developers, being unable to have them keep uv updated (most don't care about package management and I don't blame them) and yes, I do use uv directly in some bootstraping code.

One issue I had frequently with using latest uv in the past was it changing the uv lock format and output of compiled requirements files changing often. So the code validation would fail if CI is ahead of the dev.

I do perform manual bumps of uv every month or so, but the issues it causes when not fixed are not worth for me right now.

Also bumping uv for me forces some docker images to be rebuilt installing latest python and i know that I can go back in time and have an as close as possible image (but that is more of a uv limitation than a feature albeit I'm using it as one).

Anyway, the point is that you offer a way to pick an uv version, I would just like for it to pick the info from somewhere so I could have one fewer place to update.

[my1e5]

One issue I had frequently with using latest uv in the past...

Hey @inoa-jboliveira, maybe this would work for you?

uses: astral-sh/setup-uv@v7
  with:
    version-file: pyproject.toml
    resolution-strategy: lowest

Which means use the lowest value of

[tool.uv]
required-version = ">=0.5.21"

It's not as perfect as getting your pinned version from

[dependency-groups]
uv = [
    "uv==0.8.17",
]

But, if your minimum required uv version in tool.uv is in theory good enough to manage the project, then you can avoid any potential issues you might have with using the latest version?

This was added in setup-uv@v7.1.0 - https://github.com/astral-sh/setup-uv/releases/tag/v7.1.0

[inoa-jboliveira]

In this case, 0.5.17 is already picked by current implementation. It works for the dev working locally, but for ci/CD I want the locked version.

I will continue adding it manually for now then