Make default cache-dependency-path paths fit most use cases

[ssbarnea]

The current default value for cache-dependency-glob is not flexible enough to be used by most people.

cache-dependency-glob: |
  **/requirements*.txt
  **/uv.lock

A more generic value like below should cover over 99.5% of use cases:

cache-dependency-glob: |
  **/*(requirements|constraints)*.(txt|in)
  **/pyproject.toml
  **/uv.lock

Reasoning:

• There is no clear winner in battle between sort-friendly and english-syntax: test-requirements.txt vs requirements-test.txt, so supporting only one will affect ~50% users
• constraints.txt is very popular against those using constraint files
• lots of users are using .in instead of .txt extension because this is friendly with tools like dependabot, which can cause problems when mixing lock files with unlocked ones. .in is a way of saying that the file is clearly not a lock file.
• pyproject.toml should not need any explanation
• Not having a set of defaults that work for most users makes it harder to reuse the action, especially by other reusable actions/workflows, as users will need to find a way to pass customizations to the reused action. With a generic enough default, the need to it disappears.

[eifinger]

I didn't know about people using *.in files. Also, a quick GitHub search shows ~40k uses of constraints.txt. So I am fully for adding these to the default.

I am not sold on pyproject.toml. There are changes to e.g. tool configs like ruff, mypy and other stuff that doesn't need to invalidate the setup-uv cache. I am also unsure why it should be added when a we already have requirements.txt and uv.lock. For users not committing the lock file?

[eifinger]

I am not sold on pyproject.toml.

Usecases like running multiple jobs with different resolution strategies. It makes no sense to commit a lock file.

[eifinger]

I will add this as a new default.

I contemplating whether to release it as part of a new major release. This isn't really breaking anything but might be unexpectively busting caching and increasing sizes.

[patcon]

Thanks for this issue and consideration! Re: pyproject.toml

Usecases like running multiple jobs with different resolution strategies. It makes no sense to commit a lock file.

Also, people building testing general libraries that shouldn't include a lockfile

[my1e5]

I got stung today when a colleague of mine forgot to commit uv.lock when they should have. There was an entry in project.dependencies that had been erroneously removed. But since the uv.lock file was the same, setup-uv reused the cached venv and all the tests passed when they should have failed.

I have now added **/pyproject.toml to the cache-dependency-glob to protect against this scenario. But I'm in favour of pyproject.toml being part of the default config.

Whether this is 100% relevant I'm not sure, but uv itself uses pyproject.toml as the default cache-key under tool.uv. So perhaps users expect by default that any changes to the pyproject.toml should invalidate the cache?