Hacker News Reader

Comment by killertypo | Hacker News Reader

Much like Go! i'm not a big fan of languages whose includes are managed as such:

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

Does Rust, like Go, have tools for freezing dependencies? So when the git project changes, you're not left wondering why a project has sudden bugs not seen before?

I love the idea of how easy these can be included in a project, but I dislike leaning on a public repository that may change at a moments notice.

For as much as I hate Maven for some reasons, I do appreciate the ecosystem and the ease at which I can...say, ask for a specific version of a specific artifact - ensuring my application will always build.

View on HN

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-...

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.

> Does Rust, like Go, have tools for freezing dependencies?

What tools are you referring to Go here? There are a handful of extra-standard mechanisms you can use to make it somewhat better (through clever hacks on urls and such), but the expectation in go-land seems to be that 'freezing your dependencies' is 'vendor them wholesale into your git repo', which is not exactly robust. Go's story on "application will always build" is kind of notoriously bad.

I am referring to third party tools https://code.google.com/p/go-wiki/wiki/PackageManagementTool...

It would be nice to have it baked in, but thus is the life of bleeding edge development (of which I do not engage, in my safe Python Cocoon).

Yeah: http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock

That is the current state of cargo, which is unfinished. There is currently work on a repository, much like rubygems/npm.

(git dependencies managed by the author always have the problem of the repos being renamed, vanishing, moved somewhere else)

Reply on news.ycombinator.com