Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Package lock files in published crates #5093
I am not sure... Will workspace lockfile work at all for a subpackage? Perhaps we should use the lockfle that we get when we build a package during a validation step of
I am also a little bit unsure about the "unconditionally" fact: perhaps the user should be explicitly aware that the lockfile matters for
Yeah, I am not really sure, for the following reasons:
On the other hand, this literally just removes ignoring "Cargo.lock", and can't possible do any harm, and will be compatible with any fancier solution we can invent.
Yeah, I guess it's fine to r+ it as is (module a failing on windows), because it does solve the problem in 80% of the cases!
Hm, wait... Is it correct that publishing a lockfile won't break a binary? What if a binary is a workspace root, and it has path dependencies? We rewrite Cargo.toml, but we don't rewrite Cargo.lock. Would installing a binary in this situation fail with some kind of lockfile mismatch, or will we just generate a new lockfile? If the letter, let's r+, if the former, let's think about how to solve the workspace problem in a more principle way :)
Ok I've updated with a few heuristics:
That means that
added a commit
this pull request
Feb 28, 2018
Feb 28, 2018
How do I use this functionality? With the default settings, there is no
What am I missing?