cargo icon indicating copy to clipboard operation
cargo copied to clipboard

Vendored crates should be checked for changes

Open glandium opened this issue 7 years ago • 7 comments

I was building Firefox, and tried to do some changes to some rust crate. Doing so made the build fail with something like

error: the listed checksum of ... has changed:
expected: ...
actual: ...

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

That's an IMO annoying feature of cargo, but this is not what this issue is about. The problem is the following: if I actually build the crate first, and then make the changes, rebuilding just goes on acting as if I had made no change, saying Fresh $crate_name.

It seems to me cargo should fail with the exact same error as if I hadn't already built.

Cc: @alexcrichton

glandium avatar Jul 26 '18 08:07 glandium

This is currently expected behavior in that Cargo treats vendored crates like it does crates.io, it doesn't check any mtimes as it assumes it's all read-only. It is a performance optimization to not even look at the filesystem for these crates on incremental builds.

The correct way to modify a vendored crate is to use [patch] or a path dependency, and Cargo will then correctly handle the crate on incremental rebuilds as it knows that it's not a readonly dependency.

alexcrichton avatar Jul 26 '18 23:07 alexcrichton

The correct way to modify a vendored crate is to use [patch] or a path dependency, and Cargo will then correctly handle the crate on incremental rebuilds as it knows that it's not a readonly dependency.

Fortunately GNU Guix can bypass this pointless check, as I today discovered.

https://fredrickbrennan.medium.com/how-to-bypass-rust-cargo-error-directory-sources-are-not-intended-to-be-edited-ab2f257b89da

ctrlcctrlv avatar Oct 24 '22 00:10 ctrlcctrlv

When I vendor code into my repository, it changes line endings (and nothing else) which triggers this check. Is there any way to disable or at least mitigate the error in this situation?

k3d3 avatar Jan 09 '23 18:01 k3d3

Does revendor.scm not work for you?

ctrlcctrlv avatar Jan 10 '23 18:01 ctrlcctrlv

As this is expected behavior and is important for performance reasons, I'm going to propose to the cargo team that we close this.

epage avatar Oct 23 '23 21:10 epage

Instead of closing this now, I would like to see an improvement in the cargo-vendor doc. Could document that vendored sources are not intended to be modified, and [patch] is the correct way to do it.

weihanglo avatar Dec 22 '23 20:12 weihanglo

Instead of closing this now, I would like to see an improvement in the cargo-vendor doc. Could document that vendored sources are not intended to be modified, and [patch] is the correct way to do it.

cargo-vendor should have an option to generate the necessary [patch] for the vendored crates.

briansmith avatar Dec 22 '23 21:12 briansmith

claim first, question it later~ @rustbot claim

LuuuXXX avatar Feb 28 '24 02:02 LuuuXXX

#13512 has improved the doc a bit, so I am fine closing this.

cargo-vendor should have an option to generate the necessary [patch] for the vendored crates.

@briansmith feel free to open an issue if you have an idea how it would look like. Thank you :)

weihanglo avatar Mar 01 '24 21:03 weihanglo