←back to thread

265 points tosh | 1 comments | | HN request time: 0.326s | source
Show context
gchamonlive ◴[] No.44364747[source]

  # Ensure we always have an up to date lock file.
  if ! test -f uv.lock || ! uv lock --check 2>/dev/null; then
    uv lock
  fi
Doesn't this defeat the purpose of having a lock file? If it doesn't exist or if it's invalid something catastrophic happened to the lock file and it should be handled by someone familiar with the project. Otherwise, why have a lock file at all? The CI will silently replace the lock file and cause potential confusion.
replies(5): >>44364785 #>>44364880 #>>44365348 #>>44368840 #>>44370311 #
nickjj ◴[] No.44370311[source]
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.
replies(3): >>44371191 #>>44371247 #>>44378155 #
1. gchamonlive ◴[] No.44378155[source]
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!