Charlie Marsh de40f798b9 Cache tool environments in uv tool run (#4784) ... ## Summary The basic strategy: - When the user does `uv tool run`, we resolve the `from` and `with` requirements (always). - After resolving, we generate a hash of the requirements. For now, I'm just converting to a lockfile and hashing _that_, but that's an implementation detail. - Once we have a hash, we _also_ hash the interpreter. - We then store environments in `${CACHE_DIR}/${INTERPRETER_HASH}/${RESOLUTION_HASH}`. Some consequences: - We cache based on the interpreter, so if you request a different Python, we'll create a new environment (even if they're compatible). This has the nice side-effect of ensuring that we don't use environments for interpreters that were later deleted. - We cache the `from` and `with` together. In practice, we may want to cache them separately, then layer them? But this is also an implementation detail that we could change later. - Because we use the lockfile as the cache key, we will invalidate the cache when the format changes. That seems ok, but we could improve it in the future by generating a stable hash from a lockfile that's independent of the schema. Closes https://github.com/astral-sh/uv/issues/4752.		2024-07-03 19:25:39 -04:00
..
src	Cache tool environments in uv tool run (#4784)	2024-07-03 19:25:39 -04:00
Cargo.toml	Use fs_err for cachedir errors (#3304)	2024-04-29 16:33:10 +02:00