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.