I'm sorry in advance if this is a stupid question but I don't seem to understand why this is happening.
I have made something with Rust (yay) that compiles fine on my personal machine. If it matters or you want to take a look, this is the repo.
If I pull from there and download everything into a fresh folder it also compiles fine.
However, a colleague of mine did the same and the compilation fails. I'm on Linux and he's on MacOS.
It appears to be due to the fact that one of my dependencies (pdbtbx, which is a git repo) has been committed to recently which introduced breaking changes. What I don't understand is why this is a problem because I thought the
Cargo.lock file locks the exact versions I used for everything (including git commit hashes) in place so others could pull that and compile exactly what I did.
Where is the error in my reasoning?
Cargo.lock is only uploaded to Crates.io for binaries, not for libraries (by default). That may be what you are running into.
But my repo isn't on crates.io so the Cargo.lock is in fact up to date. I checked.
Crates with git dependencies can't be uploaded to crates.io in the first place. Also
Cargo.lock is ignored for dependencies. I believe OP and their college both cloned the actual repo and then tried to build it, in which case the
Cargo.lock should be respected.
There should be no error in your reasoning. Can you confirm that the commit hash on line 597 of
Cargo.lock is unchanged for your college and that it matches what is shown when building
pdbtbx? It is possible that for some reason the
Cargo.lock got updated.
Yes, we both pulled the repo from the link I provided and built locally, in case that wasn't clear.
I got back to my colleague and indeed the entries in the
Cargo.lock file match exactly. On my machine the compiler shows the same git commit hash for the git dependency as in the
Cargo.lock, on his machine it does not. This seems to be the origin of the issue.
However, I don't know why the compiler would do this.
For now I worked around the problem by having him add the
rev keyword for a specific git commit to his local
Cargo.toml but I would rather like to understand why this is happening.
Can you try
CARGO_LOG=cargo::core::workspace,cargo::core::registry,cargo::ops::resolve,cargo::core::resolver cargo build? This should give some insight in why cargo resolves crates the way it does. Note that it is very verbose. Just a single git dep already gives 150 lines of output.
Here is a link to the output which is indeed very verbose.
It's the output from my colleagues MacBook and I edited out his username, other than that nothing was changed. I looked through all instances of the
pdbtbx dependency and everywhere it comes with the same commit hash that I get during compilation (#2936a7c7).
My colleague, however, got this hash: #187175d0. But this does not occur in the generated cargo output anywhere.
[2021-11-11T12:38:30Z DEBUG cargo::core::workspace] find_root - trying /Users/username/Downloads/pdbman-latest/test/Cargo.toml
I don't see any
test dir in the published repo. Only a
tests dir. If you didn't add this crate to the main
pdbmain workspace, it will have it's own
There seems to be a misunderstanding. The repo was cloned into the folder
/Users/username/Downloads/pdbman-latest/test and is called pdbman, thus the full path for
This is analogous to the setup and build output on my own machine.
I see. @Eh2406 do you have any clue what could be going on?
I don't have a theory. Please file an issue on cargoes repo! Any effort to make it more minimal or reproducible would be helpful. But this definitely looks like a bug.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.