3 ms·

I don't understand any of the statements in this post. They don't seem to form a coherent argument, and they don't match my understanding of how lockfiles work.

I don't understand any of the statements in this post. They don't seem to form a coherent argument, and they don't match my understanding of how lockfiles work. There's a bunch of very strongly worded statements ("hack", "legacy tooling", "poor design"), but no actual explanations of _why_ or _how_ lockfiles are supposedly bad. 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_. 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. So, the main purpose for lockfiles is to A) cache a set of resolutions so that the package manager doesn't have to re-run the resolution process every time a repo is cloned and deps are installed, and B) make sure that a _consistent_ set of resolved packages is installed each time, so that you don't accidentally get newer versions that might cause different behavior. The arguments about hashes seems to ignore what lockfiles already do. They do normally include hashes of the resolved packages, both standalone and possibly as part of a download URL. The one statement that has any seeming validity is that they _can_ be "attack vectors", in that they are large, border on unreadability, and no one reads the diffs. But beyond that, this post feels like it never makes a coherent argument.

chriswarbo 2y ago
> 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

chriswarbo 2y ago

> 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