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.

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.

Would strongly recommend a lockfile if these things sound like a good idea:

- (fairly) reproducable builds in that you don't want dependencies blind-updating without knowing about it

- removing "works on my machine" issues caused by different dependency versions

- being able to cache dependency download folders in CI and use the lockfile as the cache key

This is kinda how I treat it. I figured that I have already set the requirements in the pyproject.toml file.

Should I be committing the lock file?

It's what I used to do with package-lock.json when I had little production experience.