> Package managers _are_ deterministic, but they also are reliant on the published package versions that match the listed constraints, _at the time the package

> Package managers _are_ deterministic, but they also are reliant on the published package versions that match the listed constraints, _at the time the package manager ran and generated the lockfile_. Yes, that's why "version numbers" are basically documentation; unrelated to the actual files depended on by a build (e.g. try copying random junk into `~/.m2/repository`). Hence, if we want to use those names/versions to refer to particular files, we should specify the database we're using to do the lookup (AKA the repository's "index state"). > A dep listed as `foo: ^1.2.0` will match version 1.2.3 today. If 1.3.0 or 1.9.57 is published tomorrow, it will match that newer version. hackage.haskell.org lets us specify what "today" is, via a datetime https://cabal.readthedocs.io/en/3.4/cabal-project.html?highlight=index-state#cfg-field-index-state https://cabal.readthedocs.io/en/3.4/cabal-project.html?highl... However, it's even better is to use a database that's kept in version control. There's a third-party attempt to do this for Hackage, at https://github.com/commercialhaskell/all-cabal-hashes https://github.com/commercialhaskell/all-cabal-hashes whereas crates.io does this natively at https://github.com/rust-lang/crates.io-index https://github.com/rust-lang/crates.io-index