3 ms·

Hi author here. If you end up with an invalid lock file, it doesn't silently fail and move on with a generated lock file. The `uv lock` command fails with a he

by nickjj 1y ago

Hi author here. If you end up with an invalid lock file, it doesn't silently fail and move on with a generated lock file. The `uv lock` command fails with a helpful message and then errexit from the shell script kicks in. The reason I redirected the uv lock --check command's errors to /dev/null is because `uv lock` throws the same error and I wanted to avoid outputting it twice. For example, I made my lock file invalid by manually switching one of the dependencies to a version that doesn't match the expected SHA. Then I ran the same script you partially quoted and it yields this error which blocks the build and gives a meaningful message that a human can react to: 1.712 Using CPython 3.13.3 interpreter at: /usr/local/bin/python3 1.716 error: Failed to parse `uv.lock` 1.716 Caused by: The entry for package `amqp` v5.3.4 has wheel `amqp-5.3.1-py3-none-any.whl` with inconsistent version: v5.3.1 ------ failed to solve: process "/bin/sh -c chmod 0755 bin/* && bin/uv-install" did not complete successfully: exit code: 2 This error is produced from `uv lock` when the if condition evaluates to true. With that said, this logic would be much clearer which I just commit and pushed: if test -f uv.lock; then uv lock --check else uv lock fi As for a missing lock file, yep it will generate one but we want that. The expectation there is we have nothing to base things off of, so let's generate a fresh one and use it moving forward. The human expectation in a majority of the cases is to generate one in this spot and then you can commit it so moving forward one exists.

deleted 1y ago
[deleted]
remram 1y ago
I see you just changed your article from what it was when we commented: if ! test -f uv.lock || ! uv lock --check 2>/dev/null; then uv lock; fi Your new version no longer has the bug we are talking about. I don't know why you are trying to pretend it was never there though?
- nickjj 1y ago
  > Your new version no longer has the bug we are talking about. I don't know why you are trying to pretend it was never there though? I'm not sure I understand what you mean? 1. I posted the article last week on my site 2. I noticed it was on HN today (yay) 3. I looked at the parent's comment 4. The parent's description isn't what happens with the original code 5. I made the comment you're replying to on HN to address their concerns and included a refactored version of the original condition for clarity then said I pushed the updates 6. I pushed the updates to both git and my site so both match up There's nothing to pretend about and there's no bug because both versions of the code do the same thing, the 2nd version is just easier to read and requires less `uv` knowledge to know what happens when `uv lock` runs with an invalid lock file. The history is in the HN comment I wrote and git history. It doesn't make sense to leave the original code in the blog post and then write a wall of text to explain how it worked fine but here's a modified version for clarity. Both versions of the code have the same outcome which is ensuring there's a valid lock file before syncing. What would you have done differently? I saw feedback, saw room for improvement, left an audit trail in the comments and moved on. Here's the commits https://github.com/nickjj/docker-flask-example/commit/d1b7b92868039d2b429f636c015b08a0bceaf6c0 https://github.com/nickjj/docker-flask-example/commit/d1b7b9... and https://github.com/nickjj/docker-django-example/commit/a12e2fbbc8570616bc66e4271348709d0a3a0dc1 https://github.com/nickjj/docker-django-example/commit/a12e2... btw.
  - 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.
gchamonlive 1y ago
Hi there! Congrats on the article! That revised script seems to be correct now. It'll check the lock if it exists, otherwise will generate the lock file. If this is a rule that's in agreement with all the team it's fine! > If you end up with an invalid lock file, it doesn't silently fail and move on with a generated lock file. The `uv lock` command fails with a helpful message and then errexit from the shell script kicks in. I just wanted to challenge this, because that might not be how uv behaves, or maybe my tests were wrong. I created a new test project with uv, added `requests` and manually changed the lock file to produce an error (just changed the last line, where it read `v2.32.0` or similar to `v3`). While `uv lock --check` failed with an error message, `uv lock` happily updated the file. Therefore, while I think the updated script works, it doesn't seem to be functionally equivalent to the previous revision. Or maybe we are not talking about the same kinds of issues with the lock file. How do you cause the lock file error? It's just a minor nitpick however. Thanks for taking the time to answer!

by nickjj 1y ago

deleted 1y ago

[deleted]

remram 1y ago

I see you just changed your article from what it was when we commented: if ! test -f uv.lock || ! uv lock --check 2>/dev/null; then uv lock; fi Your new version no longer has the bug we are talking about. I don't know why you are trying to pretend it was never there though?

nickjj 1y ago
> Your new version no longer has the bug we are talking about. I don't know why you are trying to pretend it was never there though? I'm not sure I understand what you mean? 1. I posted the article last week on my site 2. I noticed it was on HN today (yay) 3. I looked at the parent's comment 4. The parent's description isn't what happens with the original code 5. I made the comment you're replying to on HN to address their concerns and included a refactored version of the original condition for clarity then said I pushed the updates 6. I pushed the updates to both git and my site so both match up There's nothing to pretend about and there's no bug because both versions of the code do the same thing, the 2nd version is just easier to read and requires less `uv` knowledge to know what happens when `uv lock` runs with an invalid lock file. The history is in the HN comment I wrote and git history. It doesn't make sense to leave the original code in the blog post and then write a wall of text to explain how it worked fine but here's a modified version for clarity. Both versions of the code have the same outcome which is ensuring there's a valid lock file before syncing. What would you have done differently? I saw feedback, saw room for improvement, left an audit trail in the comments and moved on. Here's the commits https://github.com/nickjj/docker-flask-example/commit/d1b7b92868039d2b429f636c015b08a0bceaf6c0 https://github.com/nickjj/docker-flask-example/commit/d1b7b9... and https://github.com/nickjj/docker-django-example/commit/a12e2fbbc8570616bc66e4271348709d0a3a0dc1 https://github.com/nickjj/docker-django-example/commit/a12e2... btw.
- 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.

gchamonlive 1y ago

Hi there! Congrats on the article! That revised script seems to be correct now. It'll check the lock if it exists, otherwise will generate the lock file. If this is a rule that's in agreement with all the team it's fine! > If you end up with an invalid lock file, it doesn't silently fail and move on with a generated lock file. The `uv lock` command fails with a helpful message and then errexit from the shell script kicks in. I just wanted to challenge this, because that might not be how uv behaves, or maybe my tests were wrong. I created a new test project with uv, added `requests` and manually changed the lock file to produce an error (just changed the last line, where it read `v2.32.0` or similar to `v3`). While `uv lock --check` failed with an error message, `uv lock` happily updated the file. Therefore, while I think the updated script works, it doesn't seem to be functionally equivalent to the previous revision. Or maybe we are not talking about the same kinds of issues with the lock file. How do you cause the lock file error? It's just a minor nitpick however. Thanks for taking the time to answer!