astral-sh / setup-uv

Set up your GitHub Actions workflow with a specific version of https://docs.astral.sh/uv/
MIT License
200 stars 14 forks source link

Provide control over uv cache key #153

Open pvardanis opened 3 days ago

pvardanis commented 3 days ago

I work on a monorepo with multiple python projects each with its own uv.lock file. I want to be able to cache uv with a name that indicates the package name so I can be able to cache it only when needed, and also to avoid overwriting cached files that belong to different python projects. Currently it's not possible or am I missing something?

eifinger commented 3 days ago

Lets assume the following layout (based on uv workspace docs):

albatross
├── packages
│   ├── bird-feeder
│   │   ├── pyproject.toml
│   │   ├── uv.lock
│   │   └── src
│   │       └── bird_feeder
│   │           ├── __init__.py
│   │           └── foo.py
│   └── seeds
│       ├── pyproject.toml
│       ├── uv.lock
│       └── src
│           └── seeds
│               ├── __init__.py
│               └── bar.py
└── README.md

If you want to work with the bird-feeder project you can use:

- name: Use the bird-feeder cache
  id: setup-uv
  uses: astral-sh/setup-uv@v3
  with:
    enable-cache: true
    cache-suffix: "bird-feeder"
    cache-dependency-glob: "**/bird-feeder/uv.lock"

If you want to work with the seeder project you can use:

- name: Use the seeder cache
  id: setup-uv
  uses: astral-sh/setup-uv@v3
  with:
    enable-cache: true
    cache-suffix: "seeder"
    cache-dependency-glob: "**/seeder/uv.lock"

If you want a cache that gets invalidated when any of the two changes:

- name: Invalidate the cache when either project changes
  id: setup-uv
  uses: astral-sh/setup-uv@v3
  with:
    enable-cache: true
    cache-dependency-glob: "**/uv.lock"

It might be easier to maintain to just have a single cache for the whole monorepo and live with the fact that it might always contain dependency DepA even though it is only used in one project.

Based on the differences between the dependencies of your different projects it might be more efficient to use a different cache per project.

Effiency here means that the cache is smaller and therefore faster/cheaper to download from the GitHub Actions cache when one of your workflow runs starts.