[xenophonf]

The lock file shouldn't be in the repository. That forces the developers into maintenance that's more properly the responsibility of the CI/CD pipeline. Instead, the lock file should be published with the other build artifacts—the sdist and wheel(s) in Python's case. And it should be optional so that people who know what they're doing can risk breaking things by installing newer versions of locked dependencies should the need arise.

[kortilla]

It absolutely should be. Otherwise you don’t have reproducible builds.

[xenophonf]

You can reproduce the release just fine using the lock file published alongside the release. Checking it in creates unnecessary work for devs, who should only be specifying version constraints when absolutely necessary.

[zahlman]

> Checking it in creates unnecessary work for devs, who should only be specifying version constraints when absolutely necessary.

The unnecessary work of a `git commit`?

Having the file be versioned creates no requirement to update its contents any more frequently than before, and it streamlines "publishing alongside the release". The presence of the lockfile in the repo doesn't in any way compel devs to use the lockfile.