Compilation fails on other machine

Hi all,
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.

1 Like

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

https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html

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 Cargo.toml is:
/Users/username/Downloads/pdbman-latest/test/pdbman/Cargo.toml
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.