3 ms·

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.