Cache Granularity vs Build Speed: Per‑Dependency vs Full Requirements Cache Invalidation

Goal

Determine the optimal cache invalidation strategy for Read the Docs builds that balances build speed against the risk of serving stale documentation when dependencies change.

Constraints & Uncertainty

Read the Docs uses an internal hash of the requirements.txt to decide whether to reuse cached build artifacts. The hashing algorithm is not exposed, and there is no public API to trigger partial cache purges. It is unclear whether the system can detect a single dependency update or if any modification to the file forces a full cache rebuild.

Questions

• Does Read the Docs currently invalidate the entire cache whenever any line in requirements.txt changes, or can it detect and react to specific dependency updates?
• If only full-file changes trigger invalidation, would a per‑dependency granularity significantly reduce build times without compromising artifact correctness?
• Is there an option, either via configuration or an API, to customize cache invalidation granularity for future releases?