Add support for dynamic cache keys

[charliermarsh]

Summary

This PR adds a more flexible cache invalidation abstraction for uv, and uses that new abstraction to improve support for dynamic metadata.

Specifically, instead of relying solely on a timestamp, we now pass around a CacheInfo struct which (as of now) contains Option<Timestamp> and Option<Commit>. The CacheInfo is saved in dist-info as uv_cache.json, so we can test already-installed distributions for cache validity (along with testing cached distributions for cache validity).

Beyond the defaults (pyproject.toml, setup.py, and setup.cfg changes), users can also specify additional cache keys, and it's easy for us to extend support in the future. Right now, cache keys can either be instructions to include the current commit (for setuptools_scm and similar) or file paths (for hatch-requirements-txt and similar):

[tool.uv]
cache-keys = [{ file = "requirements.txt" }, { git = true }]

This change should be fully backwards compatible.

Closes #6964.

Closes #6255.

Closes #6860.

[charliermarsh]

Going to move the #7028 part into its own commit, since it's largely independent.

[konstin]

Suggested change

[konstin]

Given that we always read the default three files, should this be called extend-cache-keys, mirroring ruff's extend- settings?

[zanieb]

I don't feel strongly about this, but we don't use extend- at all in uv yet and you won't be able to change the base cache keys so I don't think it's necessary here.

[konstin]

I'm not particular on the specific naming, but i think it's an odd design that we expose a cache-keys setting that then doesn't let you configure the cache keys, but add files/git to our immutable defaults.

[charliermarsh]

What if we make our current settings a default, and this overrides them?

[konstin]

I'd find that more intuitive. It's a bit annoying that you have to re-specify pyproject.toml and/or setup.py, which i assumed that's what you wanted to avoid with that design; but personally i like just specifying all relevant files.

[zanieb]

Certainly an option, but are there cases where you would actually want to ignore changes to those other files?

[charliermarsh]

I guess one upside is that we could document the default more clearly...? I'm torn here though, I guess I don't feel strongly either way.

[codspeed-hq]

CodSpeed Performance Report

Merging #7136 will not alter performance

_{Comparing charlie/dynamic-cache (d366c7e) with main (9a7262c)}

Summary

✅ 14 untouched benchmarks

[sbidoul]

Ooh, this is interesting. ❤️
Could file accept a glob pattern?

[charliermarsh]

I don't see why not, though it will get slower as you add more files hah.

[charliermarsh]

Can you give an example of how you'd use it? Just curious.

[sbidoul]

In Odoo projects (using the hatch-odoo build backend), we have dynamic dependencies computed from Odoo addons manifests. So I'd use odoo/addons/*/__manifest__.py.