Summary
Summary:
When two people check out the same project at different paths relative to UV_CACHE_DIR, the relative paths written in uv.lock differ for each user. This is because the paths are currently calculated relative to the project directory rather than the cache directory. Although the paths will be recalculated as needed and do not prevent the project from working, this inconsistency leads to unnecessary modifications in the uv.lock file. As a result, Git will show the lock file as changed, even when there are no real updates, such as new package versions, that need to be committed. This creates confusion and noise in version control, making it harder to track legitimate changes to dependencies.
Minimal reproducible example:
- Person A checks out the project at
/home/alice/project and has UV_CACHE_DIR at /home/alice/.cache/uv.
- Person B checks out the same project at
/Users/bob/dev/project and has UV_CACHE_DIR at /Users/bob/.cache/uv.
- Run
uv in both environments to generate a uv.lock file (e.g., uv pip install -r requirements.txt).
- Observe that the relative paths written in
uv.lock differ based on the depth of the project relative to the cache directory.
- Use
git status and see that uv.lock is marked as modified, even though no package changes occurred.
Expected behavior:
Relative paths in uv.lock should always be resolved relative to UV_CACHE_DIR, not the project directory, so that the lock file is consistent regardless of where the project is checked out.
Actual behavior:
Relative paths in uv.lock are currently calculated relative to the project directory, resulting in inconsistencies when the project is checked out at different depths compared to the cache directory. This leads to unnecessary changes being detected by Git.
Proposed solution:
Keep all paths in the uv.lock file relative to UV_CACHE_DIR, not the project directory.
Platform
Ubuntu 24.04.1 LTS (Noble Numbat), x86_64 Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 GNU/Linux
Version
uv 0.8.4
Python version
Python 3.11.10
Summary
Summary:
When two people check out the same project at different paths relative to
UV_CACHE_DIR, the relative paths written inuv.lockdiffer for each user. This is because the paths are currently calculated relative to the project directory rather than the cache directory. Although the paths will be recalculated as needed and do not prevent the project from working, this inconsistency leads to unnecessary modifications in theuv.lockfile. As a result, Git will show the lock file as changed, even when there are no real updates, such as new package versions, that need to be committed. This creates confusion and noise in version control, making it harder to track legitimate changes to dependencies.Minimal reproducible example:
/home/alice/projectand hasUV_CACHE_DIRat/home/alice/.cache/uv./Users/bob/dev/projectand hasUV_CACHE_DIRat/Users/bob/.cache/uv.uvin both environments to generate auv.lockfile (e.g.,uv pip install -r requirements.txt).uv.lockdiffer based on the depth of the project relative to the cache directory.git statusand see thatuv.lockis marked as modified, even though no package changes occurred.Expected behavior:
Relative paths in
uv.lockshould always be resolved relative toUV_CACHE_DIR, not the project directory, so that the lock file is consistent regardless of where the project is checked out.Actual behavior:
Relative paths in
uv.lockare currently calculated relative to the project directory, resulting in inconsistencies when the project is checked out at different depths compared to the cache directory. This leads to unnecessary changes being detected by Git.Proposed solution:
Keep all paths in the
uv.lockfile relative toUV_CACHE_DIR, not the project directory.Platform
Ubuntu 24.04.1 LTS (Noble Numbat), x86_64 Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 GNU/Linux
Version
uv 0.8.4
Python version
Python 3.11.10