CI cache key refers to non-existent uv.lock file

[yiyunliu]

The current CI configuration (e.g. lint.yml) constructs the cache key by hashing uv.lock file, which isn't in version control.

The consequence is that the cache key is a constant (see the CI caches page) and never gets invalidated no matter how the project worktree is modified . Not having the CI package versions visible makes issues like #630 hard to debug, when there's a discrepancy between the CI environment and a fresh local environment.

I can create a PR and commit a uv.lock file.

[eb8680]

I'd rather not commit uv.lock, I think that's usually a bad idea for code that's intended to be used by other people or projects. It adds a bunch of clutter and merge conflicts to open PRs. More importantly, if the codebase isn't robust to minor variations in developer environments that still fall within the boundaries of pyproject.toml it definitely won't be robust in downstream usage, because downstream codebases aren't beholden to our uv.lock, only our pyproject.toml.

As for CI cache invalidation, I think there are reasonable heuristics we could use to do this periodically in lieu of a globally shared uv.lock. For example, we might want to invalidate the cache if an upstream dependency is updated, or if we modify pyproject.toml, or if some minimum amount of time (1 week?) has passed.

[yiyunliu]

I think adding pyproject.toml is definitely the right heuristic to get the cache invalidation issue sorted. Having a uv.lock file globally is a bad idea like you said, but I think it's still good have a local uv.lock file that's not in the project root but used exclusively by the CI to make it easier to debug the CI and reproduce the CI environment locally.

[yiyunliu]

I made a PR that simply replaces uv.lock with pyproject.toml. I didn't add uv.lock.ci file because it would still clutter the commit history.