4 ms·
> The parent's description isn't what happens with the original code Yes, it is: both gchamonlive and myself pointed out that if your lock file exists and is o
by remram 1y ago
> The parent's description isn't what happens with the original code
Yes, it is: both gchamonlive and myself pointed out that if your lock file exists and is out of date, your (previous) script would silently update it before installing. This would happen because `uv lock --check` would return false, triggering the call to `uv lock`.
Your new version no longer does that, because you removed `! uv lock --check` from the condition.
- nickjj 1y ago> Yes, it is: both gchamonlive and myself pointed out that if your lock file exists and is out of date, your (previous) script would silently update it before installing Check my original comment, it doesn't operate like this. You can try it yourself in the same way I outlined in the comment. `uv lock` fails if your lock file has a mismatch and will produce a human readable error saying what's wrong.
- remram 1y ago> `uv lock` fails if your lock file has a mismatch Now you seem even more confused. Do you mean `uv sync` will fail? `uv lock` is literally the command you run when there's a mismatch between pyproject.toml and uv.lock to update uv.lock. That's why it's called lock. Here's a full reproducer: https://gist.github.com/remram44/21c98db9a80213b2a3a5cce959d9792b https://gist.github.com/remram44/21c98db9a80213b2a3a5cce959d... Check out branch "previous-blog". Run `docker build . -t uvtest`. You will see that it builds with no error, and if you run `docker run uvtest cat /app/uv.lock`, you will see that the uv.lock in the image is NOT the one in the repo. It has been updated silently, which is what gchamonlive and myself pointed out. Now check out branch "master". Run `docker build . -t uvtest` again. You will see `error: The lockfile at `uv.lock` needs to be updated` which is what you say always happened.