-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Validate locked versions against constraints in lock file #12276
Comments
If the lockfile is edited outside of uv, we don't make any guarantees about keeping it in-sync with the |
We're not using Dependabot on this particular project. On further investigation, the error was in fact introduced as part of a Git merge conflict resolution. Do you know of a recommended way to avoid this happening in future beyond just telling everyone on the team not to try and do manual resolution on |
We're trying to add more validations like #12235 to catch this, but yeah in general not trying to conflict-resolve locks is a good policy. |
Does it make sense to raise a separate feature request of "validate that the package versions in |
Yeah I think we'd be happy to accept this kind of improvement, especially if it's as straight-forward as you suggest. |
uv lock
doesn't detect incompatible locked version
Summary
If
uv.lock
has locked a version that is incompatible withpyproject.toml
, thenuv lock
anduv sync
don't detect the incompatibility. However,uv.lock
does record the version constraints frompyproject.toml
- it should be fairly straightforward to check that all locked versions satisfy the constraints in the lockfile before using it.Running
uv lock --upgrade
orrm uv.lock; uv lock
fixes the lockfile, but ideally this should be caught as an invalid lockfile rather than passing silently as it does currently.Here's a minimal reproduction of the problem, which can be caused by someone erroneously trying to manually resolve a merge conflict in uv.lock:
Example files
pyproject.toml
.python-version
uv.lock
Given the files above, we have
Note that we get
numpy==2.2.4
, despite the fact that we explicitly specifynumpy!=2.2.4
inpyproject.toml
!This invalid lockfile thankfully doesn't seem to appear organically - but it might be created as the result of manually resolving a Git merge conflict. However, once the invalid lockfile is there, it silently gives erroneous results.
Suggested resolution
Ideally, uv would check that the locked version of numpy (2.2.4) satisfies any constraints in the lockfile, such as the one in
packages[0].metadata
specifyingnumpy!=2.2.4
. Given that we are just checking version constraints (and erroring out if any don't match) rather than performing any kind of solve, this should be straightforward to implement and should not present a performance hit. Additionally, this shouldn't ever affect a valid (uv-created) lockfile, only ones that have been modified by something other than uv.The text was updated successfully, but these errors were encountered: