←back to thread

Switching Pip to Uv in a Dockerized Flask / Django App

(nickjanetakis.com)
265 points tosh | 2 comments | 24 Jun 25 09:46 UTC | HN request time: 0.425s | source
Show context
gchamonlive ◴[24 Jun 25 10:48 UTC] 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 ◴[24 Jun 25 10:57 UTC] 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 #
1. burnt-resistor ◴[24 Jun 25 11:22 UTC] No.44364943[source]▶
In the almost every world, Ruby and elsewhere too, constraints in library package metadata are supposed to express the full supported possibilities of allowed constraints while lock files represent current specific state. That's why they're not committed in that case to allow greater flexibility/interoperability for downstream users.

For applications, it's recommended (but still optional) to commit lock files so that very specific and consistent dependencies are maintained to prevent arbitrary, unsupervised package upgrades leading to breakage.

replies(1): >>44369462 #
2. MrJohz ◴[24 Jun 25 18:46 UTC] No.44369462[source]▶
I know Cargo recommended your approach for a while, but ended up recommending that all projects always check in a lock file. This is also the norm in most other ecosystems I've used including Javascript and other Python package managers.

When you're developing a library, you still want consistent, reproducible dependency installs. You don't want, for example, a random upgrade to a testing library to break your CI pipelines or cause delays while releasing. So you check in the lock file for the people working on the library.

But when someone installs the library via a package manager, that package manager will ignore the lock file and just use the constraints in the package metadata. This avoids any interoperability issues for downstream users.

I've heard of setups where there are even multiple lock files checked in so different combinations of dependency can be tested in CI, but I've not seen that in practice, and I imagine it's very much dependent on how the ecosystem as a whole operates.