For what it's worth I think Go's MVS somewhat meets the desire here. It does not require lockfiles, but also doesn't allow use of multiple different minor/patch versions of a library: https://research.swtch.com/vgo-mvs

I believe Zig is also considering adopting it.

If there are any dependencies with the same major version the algorithm simply picks the newest one of them all (but not the newest in the package registry), so you don't need a lockfile to track version decisions.

Go's go.sum contains checksums to validate content, but is not required for version selection decisions.

▲

nycticorax 4 days ago | parent | next [-]

Strongly endorse. That paper is really wonderful. It seems to me that MVS is the solution to the version selection problem, and now we just have to wait for awareness of this to fully percolate through the developer community.

▲

vl 4 days ago | parent | prev [-]

Indirect require section in go.mod file is essentially a lockfile. Once decision is made by tool, it's codified for future builds.

	▲	maxmcd 4 days ago \| parent \| next [-]
		The //indirect dependencies I believe are just there to track dependencies that are not in the project, or to help with caching: https://github.com/golang/go/issues/36460 In go 1.17 they were added so that project loading did not require downloading the go.mod of every dependency in the graph.
	▲	arccy 3 days ago \| parent \| prev [-]
		The decision process is deterministic and requires no human input, it's only there for caching / speed, so it's not like a traditional lockfile. You can delete the indirect section and it will be reconstructed exactly as before.