←back to thread

264 points tosh | 1 comments | | HN request time: 0.212s | 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 #
9dev ◴[] No.44364880[source]
What are the possible remediation steps, however? If there is no lock file at all, this is likely the first run, or it will be overwritten from a git upstream later on anyway; if it's broken, chances are high someone messed up a package installation and creating a fresh lock file seems like the only sensible thing to do.

I also feel like this handles rare edge cases, but it seems like a pretty straightforward way to do so.

replies(4): >>44364906 #>>44364907 #>>44364927 #>>44366724 #
JimDabell ◴[] No.44364927[source]
If the lock file is missing the only sensible thing to do is require human intervention. Either it’s the unusual case of somebody initialising a project but never syncing it, or something has gone seriously wrong – with potential security implications. The upside to automating this is negligible and the downside is large.
replies(1): >>44365056 #
guappa ◴[] No.44365056[source]
? It has always been the case that if you don't specify a version, the latest is implied.
replies(1): >>44365078 #
slau ◴[] No.44365078[source]
Whether it’s the latest or not is irrelevant. What’s important is the actual package hash. This is the only way to have fully reproducible builds that are immune to poison-the-well attacks.
replies(1): >>44367295 #
1. guappa ◴[] No.44367295[source]
That would be true if anyone actually ever reviewed the dependencies. Which is not the case. So the version doesn't matter when any version is as likely to contain malware.