> specify library versions explicitly

Sometimes even that is not helpful. It's a pain we have to deal with.

How is it not helpful?

A dependency lock file with resolved versions for both direct and transient dependencies = reproducible build

	▲	blincoln 3 days ago \| parent \| next [-]
		I don't know how common this is, but the fschat library maintainers went for at least a year without making an official release or updating the version number in their GitHub repo, so the only way to both have current code and a reproducible build (without just including the fschat library directly, of course) was to pin it to a particular GitHub commit hash, which would get you code that was current, but with the version number from 12+ months earlier. fschat is pretty popular for LLM-related work, so I assume this is at least not unheard-of for other notable third-party libraries.
	▲	mkagenius 3 days ago \| parent \| prev [-]
		I don't remember the exact scenario but it might have been related to the underlying python or some sys library being a little different and then the dependency lock not being compatible with it.