4 ms·

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 t

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
        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.
whyever 12y ago
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.

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

whyever 12y ago

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.