Help with Vendoring dependencies

Hi! I have the following issue:
I want to write an application but I'm required to vendor in dependencies. I've dowloaded everything with cargo vendor and made the .cargo/config.toml specifying I want to use the vendored dependencies. When I try to build the application cargo fails with the following:

error: the listed checksum of `C:\Users\ELOSER\git\mkt_utils\vendor\base64\src/write/mod.rs` has changed:
expected: 73cd98dadc9d712b3fefd9449d97e825e097397441b90588e0051e4d3b0911b9
actual:   252e2e1ca4d659844761b399ffc0f52642b570c97d2f0ddf38fd62f0d83ea1f8

directory sources are not intended to be edited, if modifications are required then it is recommended that `[patch]` is used with a forked copy of the source

Is there a way to disable checking the checksums?
(To vendor the dependencies I had to download them in a linux server using rustup target add x86_64_pc-windows-mvsc and downloaded the required dependencies)
Thanks!!

No. As the error message suggest, if you need to change base64, you need to either patch it or use a path dependency instead. From the docs:

Cargo treats vendored sources as read-only as it does to registry and git sources. If you intend to modify a crate from a remote source, use [patch] or a path dependency pointing to a local copy of that crate. Cargo will then correctly handle the crate on incremental rebuilds, as it knowns that it is no longer a read-only dependency.

The toolchain shouldn't make any difference to cargo vendor, as it only vendors the source code of the dependencies, not any prebuilt artefacts.

Thanks for the reply,
This approach works however, I fear I will need to replace every transitive dependency of my project. That's why I though there might be another way of doing this

If you patch base64 once, it will be applied transitively to all your other dependencies that also themselves depend on base64.

2 Likes

Little update, I've added all the patches from the vendor directory with a python script, however I'm still having trouble with hashes:

error: the listed checksum of `C:\Users\ELOSER\git\mkt_utils\vendor\async-channel\tests/unbounded.rs` has changed:
expected: 1bed2b00f11495247f4a5084f553016bf4cbf6136ad159a776dcbd9a8bc29f3c
actual:   a89eaff7c47e9cd591a4194cf1f63f8548a94700182dc11ee96d3013e3e26796

directory sources are not intended to be edited, if modifications are required then it is recommended that `[patch]` is used with a forked copy of the source

The offending crate:

[patch.crates-io]
ahash = { path = "./vendor/ahash" }
allocator-api2 = { path = "./vendor/allocator-api2" }
# async-channel = { path = "./vendor/async-channel", version = "1.9.0" }
async-channel = { path = "./vendor/async-channel-1.9.0" }
async-executor = { path = "./vendor/async-executor" }

I must be misunderstanding something!
Here's the complete Cargo.toml file

You need to make your changes in, and point the patch at, a path which is not part of the vendor directory.

Do you have an example of how will Cargo.toml look like?

If you made changes to base64 and async-channel, I'd expect your Cargo.toml to have a section that looks like this:

[patch.crates-io]
base64 = { path = "./base64" }
async-channel = { path = "./async-channel" }

where ./base64 and ./async-channel are the directories that contain the source code of the two patched crates with the changes you made.

Did you intentionally change the source code of the base64 crate? Or do you just want to use the original code with no modifications?

If the checksum failed even though you didn’t modify the crate, something else must be modifying it, and you should figure out what it is. For example, you might need to disable git’s line-ending handling.

2 Likes

I'm passing these dependencies between a linux server and a windows pc so that must be the problem. Thanks for the advice!

I haven't made any changes to the crate's sourcecode so another thing must be at play here

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.