As I understand this, some crate authors have cargo.lock in their gitignore file but cargo still uses/creates/picks up cargo.lock fil?
I have a separate vendor dir that is in VCS as separate repo and because of this change (probably) Cargo.lock was ignored because it was in gitignore. This resulted in failing cargo builds when I was trying to build Python wheels (cdylibs) like pydantic_core which uses rust.
I tried to build pydantic_core 2.x for example and I get this error
error: failed to calculate checksum of: /srv/rust_vendored/hashbrown-0.16.1/Cargo.lock
Caused by:
failed to open file `/srv/rust_vendored/hashbrown-0.16.1/Cargo.lock`
This is due to Cargo.lock missing from my vendor repo, because it was in that crate's gitignore.
Is there any solution to this instead of manipulating vendored crates' gitignore files?
the linked patch is about what cargo will include when packaging for crates before uploading to crates.io, I don't think it is relevant to vendored code.
what's more, cargo only uses the lock file from the workspace (the root crate if no virtual workspace is used) when it builds a crate, lock files of dependencies are ignored.
can you provide more details about your building environment setup, things like which crate is the root being built, which dependencies are vendored, what's the structure of the repositories, what's the content of .gitignore, etc?
the short message only shows the failure is related to the lock file of hashbrown, more information is needed for a conclusion.
I have a separate repo for all the rust vendored deps which are used when building Python wheels. I have sdist for Python wheel for example pydantic_core-2.46.4.tar.gz which requires hashbrown 0.16.1 to be present to build the python wheel.
My question is: when I cargo vendor to fetch those crates (and keep them in a separate repo for instance), and the unpacked crate has .gitignore that has Cargo.lock in it as an entry, it excludes that in the git repository. Is this typical vendoring behavior?
hashbrown's gitignore
/target
**/*.rs.bk
Cargo.lock
I realized cargo vendor --versioned-dirs doesn't download .gitignore but downloading crate from crates.io as tarball includes it.
ok, I think I understand your situation now. this is indeed an interesting edge case.
as I said, lock files from dependencies are NOT actually used for the build, but cargo need to check the integrity of the crate source before building. so even if it is not needed, because the lock file is included in the crate tarball, there's a checksum entry for it (in the .cargo-checksum.json file).
in my opinion, it's hashbrown's fault to include the lock file in the package but not remove the entry in .gitignore, or actually, they should exclude the .gitignore from the package all together. it is useless to include in the tarball.
this problem only appears when you vendor the crate source and added the vendored files to the git repo. because of the .gitignore file, when the repo is checked out to a different work tree, the lock file will be missing.
in a "normal" (non-vendored) situation, the lock file is always present, despite the .gitignore file, so it is not discovered earlier.
to work around this issue, I suggest you re-vendor the dependencies, and then simply remove all the .gitignore files from the vendored source. you should already have a .gitignore in the repo root, and they are useless anyway.