Support for uv Package Manager Caching

[mgaitan]

Description
Hey there! I'm suggesting we add caching support for the uv package manager in setup-python. uv (uv pip command currently) is a drop-in replace for pip, using requirements.txt or any other input file that pip supports for dependencies definitions. The only difference is its cache directory: setup-python uses the output of pip cache dir to find the cache directory, but uv uses uv cache dir instead (see astral-sh/uv#1734). It should be a straightforward addition that could help projects using uv.

Justification
uv is 10-100x faster than pip. There is a lot of interest from the community to use this new tool in CI environments (e.g astral-sh/uv#1386)

Are you willing to submit a PR?
Yep! Happy to help out and get my hands dirty with a PR to make this happen. However, I'm far of being a Typescript expert.

[nschloe]

You could also just cache the uv cache directory, e.g.,

      - uses: actions/cache@v4
        id: cache-uv
        with:
          path: ~/.cache/uv
          key: ${{ runner.os }}-python-${{ matrix.python-version }}-uv

[acostapazo]

You could also just cache the uv cache directory, e.g.,

      - uses: actions/cache@v4
        id: cache-uv
        with:
          path: ~/.cache/uv
          key: ${{ runner.os }}-python-${{ matrix.python-version }}-uv

I have just tested this solution and I think it is not worth using it when your requirements are large packages.

I've added the cache in my public playground with alice-biometrics/uv-playground@14871e8

And run a workflow to test what happens when run without cache: https://github.com/alice-biometrics/uv-playground/actions/runs/8046635708/job/21974

241996

surprisingly, the size of the cache is very large, so it takes a long time to save in the post-cache.

Then, I run it again to test how works with a saved cache: https://github.com/alice-biometrics/uv-playground/actions/runs/8046670133/job/21974345476

The installation time is extremely fast, however, it takes the same amount of time to retrieve the cache as it does to install in a fresh environment with uv.

Example of a workflow without uv cache: https://github.com/alice-biometrics/uv-playground/actions/runs/7986874748/job/21808164311

[akx]

Heh, I actually wrote a PR that implements this (before this issue, to boot), but no actions/setup-python maintainer seems to have seen it: #818

[alechouse97]

I've been playing with replacing pip with uv in our Gitlab CI pipeline, and it massively speeds up installing packages when you've got the cache. However, I've noticed that the uv cache is notably larger than the pip one (along with significantly more files), and the increase in Gitlab's cache time almost outweighs the shift to uv. Anyone else run into this?

[edgarrmondragon]

I've been playing with replacing pip with uv in our Gitlab CI pipeline, and it massively speeds up installing packages when you've got the cache. However, I've noticed that the uv cache is notably larger than the pip one (along with significantly more files), and the increase in Gitlab's cache time almost outweighs the shift to uv. Anyone else run into this?

I think that's essentially the same that's reported in #822 (comment)

[kdeldycke]

Another strategy worth considering would be to cache the whole .venv, as demonstrated in this article: https://adamj.eu/tech/2023/11/02/github-actions-faster-python-virtual-environments/

[charliermarsh]

I did some analysis on the uv-playground repo described here by @acostapazo. Interestingly, the pip cache is even larger than the uv cache (2.8 GB vs. 2.2 GB) though both are of course very large. Almost the entirety of the cache (at least in the uv case, I'm less familiar with pip's cache structure) are the enormous torch and nvidia_cudnn_cu12 wheels.

My guess is that it's less efficient for uv to run through the cache in such cases (big pre-built wheels) than it is to install from scratch. The main case where this would not be true is if you had to build things from source, where caching can have a huge impact. I'm experimenting with a uv command (astral-sh/uv#5391) that would enable you to clear pre-built wheels from the cache, but retain anything that was built from source, to get the best of both worlds.

[EwoutH]

Example from our repo: Pandas doesn't have Python 3.13 wheels out yet, but Pandas 2.2.2 can be build on Python 3.13. So it now takes around ~4 minutes to build, either with uv pip or an uncached pip. While cached pip takes only 30 seconds, uv takes only 3 seconds on Python 3.12 where all wheels are available.

So in the case wheels are not yet up yet, caching would provide huge value if also supported for uv.

[eifinger]

I have created an action to install uv and modelled it so it can nearly be used as a drop in replacement: https://github.com/eifinger/setup-uv

A simple example workflow could look like this:

- name: Checkout the repository
  uses: actions/checkout@main
- name: Install the latest version of uv
  uses: eifinger/setup-uv@v1
  with:
    enable-cache: true
- name: Test
  run: uv run --frozen pytest

EDIT: My action got adopted by Astral and is now astral-sh/setup-uv

[hugovk]

I've also been trying out https://github.com/hynek/setup-cached-uv

jobs:
  tests:
    runs-on: ubuntu-latest  # or macOS, or Windows
    steps:
      - uses: hynek/setup-cached-uv@v2

      - run: uv ...

[codespearhead]

Should this be closed in favor of [1]? UV already keeps track of the Python version to install in source control.

- name: Enable caching
  uses: astral-sh/setup-uv@v3
  with:
    enable-cache: true

[1] https://github.com/astral-sh/setup-uv?tab=readme-ov-file#enable-caching

[hugovk]

See also https://github.com/hynek/setup-cached-uv

jobs:
  tests:
    runs-on: ubuntu-latest  # or macOS, or Windows
    steps:
      - uses: hynek/setup-cached-uv@v2

      - run: uv ...