←back to thread

264 points tosh | 1 comments | | HN request time: 0.207s | 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 #
freetonik ◴[] No.44364785[source]
In the Python world, I often see lockfiles treated a one "weird step in the installation process", and not committed to version control.
replies(5): >>44364943 #>>44364950 #>>44365064 #>>44366872 #>>44375347 #
slau ◴[] No.44365064[source]
In my experience, this is fundamentally untrue. pip-tools has extensive support for recording the explicit version numbers, package hashes and whatnot directly in the requirements.txt based on requirements.in and constraints files.

There are many projects that use pip-compile to lock things down. You couldn’t use python in a regulated environment if you didn’t. I’ve written many Makefiles that explicitly forbid CI from ever creating or updating the actual requirements.txt. It has to be reviewed by a human, or more.

replies(2): >>44366180 #>>44366721 #
1. Hasnep ◴[] No.44366180[source]
They're not saying that's how it's supposed to be used, they're saying that's how it's often used by people who are unfamiliar with lock files