Summary
The user discusses the caching capabilities of the uv package manager, questioning claims about its lack of a caching mechanism. They reference sources indicating that uv uses aggressive caching to avoid re-downloading dependencies and seek clarification on whether this caching is limited to the same virtual environment or operates system-wide. The user notes that recreating a virtual environment suggests a shared cache and mentions that a blog post about uv is outdated due to recent changes, referencing Astral's documentation on cache optimizations in containers. They also highlight the oversight of not mentioning rye, which manages multiple Python toolchains and dependencies, and bundles both uv and ruff.
daniel.mantei
It seems like a major oversight to write an article about uv without mentioning rye, which installs and manages multiple python toolchains, installs and manages global and per-project (venv) dependencies, and bundles both uv and ruff (astral-sh's super fast linter) as well.
Check it out here:
https://github.com/astral-sh/rye|https://github.com/astral-sh/rye
vlad
Charlie also invested in Earthly :wink:
vlad
I think Evan is right - we should probably refresh our article as it's lagging behind. FWIW Charlie is a beast and keeps improving uv faster than we can write articles about it lol.
evan.shenkman
FYI, that blog post is 3 months old. Lots of things have changed in uv since that post was written. Astral has docs on using uv inside of a container with cache optimizations.
hqi
From https://earthly.dev/blog/python-uv/ it says > Another limitation of uv is that it lacks https://en.wikipedia.org/wiki/Containerization_(computing)|containerization capabilities. It has no caching mechanism to help speed up the build process by reusing identical dependencies in different virtual environments Is this no caching mechanism statement true?
What kind of caching is uv docs using here? https://docs.astral.sh/uv/concepts/cache/ > uv uses aggressive caching to avoid re-downloading (and re-building dependencies) that have already been accessed in prior runs. Does the entire page of uv's caching capabilities only only apply to the same virtual environment?
https://blog.kusho.ai/uv-pip-killer-or-yet-another-package-manager/ says uv uses a global module cache . Global sounds like at system level across virtual environments
From https://astral.sh/blog/uv, 80-115x faster when running with a warm cache (e.g., recreating a virtual environment or updating a dependency)
Recreating a virtual environment sounds like the cache is applied across virtual environments