6 ms·

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

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.

ben0x539 12y ago
Yeah: http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock
dbaupp 12y ago
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 https://github.com/servo/servo/blob/master/Cargo.lock (machine generated/consumed) [1]: http://doc.crates.io/manifest.html#the-%5Bdependencies.*%5D-sections http://doc.crates.io/manifest.html#the-%5Bdependencies.*%5D-...
- killertypo 12y ago
  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.
  - stormbrew 12y ago
    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.
    - giovannibajo1 12y ago
      To further clarify a detail that might not be obvious, the lock file is designed to be committed.
      - steveklabnik 12y ago
        That's true and not true: http://doc.crates.io/faq.html#why-do-binaries-have-cargo.lock-in-version-control,-but-not-libraries http://doc.crates.io/faq.html#why-do-binaries-have-cargo.loc...?
        stormbrew 12y ago
        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.
        steveklabnik 12y ago
        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.
stormbrew 12y ago
> 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.
- killertypo 12y ago
  I am referring to third party tools https://code.google.com/p/go-wiki/wiki/PackageManagementTools 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).
Argorak 12y ago
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)

ben0x539 12y ago

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

dbaupp 12y ago

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 https://github.com/servo/servo/blob/master/Cargo.lock (machine generated/consumed) [1]: http://doc.crates.io/manifest.html#the-%5Bdependencies.*%5D-sections http://doc.crates.io/manifest.html#the-%5Bdependencies.*%5D-...

killertypo 12y ago
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.
- stormbrew 12y ago
  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.
  - giovannibajo1 12y ago
    To further clarify a detail that might not be obvious, the lock file is designed to be committed.
    - steveklabnik 12y ago
      That's true and not true: http://doc.crates.io/faq.html#why-do-binaries-have-cargo.lock-in-version-control,-but-not-libraries http://doc.crates.io/faq.html#why-do-binaries-have-cargo.loc...?
      - stormbrew 12y ago
        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.
        steveklabnik 12y ago
        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.

stormbrew 12y ago

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

killertypo 12y ago
I am referring to third party tools https://code.google.com/p/go-wiki/wiki/PackageManagementTools 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).

Argorak 12y ago

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)