Hacker News Reader

Comment by dbaupp | Hacker News Reader

I'm not a Go expert at all, but I believe Cargo (the dependency management tool) far surpasses Go in this respect.

One of the main design goals for Cargo is reproducable builds. E.g. the first time anything is build Cargo will create a Cargo.lock[0] file that fixes the dependency at the exact commit that the build used, so one can come back in a year and rerun to get the same result (assuming upstream hasn't edited their history). Upgrading/changing a dep then requires explicitly calling `cargo upgrade`.

One can also manually specify versions and exact commits[1] in the Cargo.toml (the file written to specify those deps), e.g.

  [dependencies.lazy_static]
  git = "https://github.com/Kimundi/lazy-static.rs"
  version = "1.1"

[0]: e.g. https://github.com/servo/servo/blob/master/Cargo.lock (machine generated/consumed)

[1]: http://doc.crates.io/manifest.html#the-%5Bdependencies.*%5D-...

View on HN

Thanks! I would much rather prefer being forced to specify a version than not. Consider building with more than one developer in mind. Or a developer joins the team a year down the road. Why waste anyones time not taking a moment to say "no we need v.1.1".

Good to see none the less!

TIL.

You are effectively forced to specify a version thanks to the lock file. It just assumes that in the moment you specify the dependency you mean the version you currently have access to. This is the same mechanism as Ruby with Bundler uses, and it is very friendly to multi-dev teams, the version they need to be on page with everyone else is right there in the lock file.

To further clarify a detail that might not be obvious, the lock file is designed to be committed.

That's true and not true: http://doc.crates.io/faq.html#why-do-binaries-have-cargo.loc...?

Is there a rationale for not just ignoring the lockfile of dependencies rather than insisting they not have them at all? I actually have always found this duality in bundler irritating, as when I work on a gem with someone I still want to be able to communicate an ideal dependency state. Not hanging a lockfile makes this difficult.

Well, if your gem didn't work with a particular combination of dependencies, that should be reflected in the version constraints. I'm not sure what an 'ideal' state is.

I'm not 100% sure if there's an official answer, exactly, but it's more representative of the state of affairs. If you do check a lockfile in, it will be ignored.

By ideal here I mean something more like known-good. A baseline of expected behavior against which I can compare. The permutations of version combinations in a typical 'production' dependency specification can get very large, and there just as much benefit to having devs start from the same working version for a library as a program.

Note that it is encouraged by convention to check your Cargo lock file into your VCS if you are developing an application. This means that everyone checking out your code will build your application using exactly the same versions of the dependencies you used when you committed the lock file.

Reply on news.ycombinator.com