Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cargo vendor doesn't re-vendor if the version number hasn't changed #8181

Closed
jsgf opened this issue Apr 29, 2020 · 1 comment · Fixed by #14530
Closed

cargo vendor doesn't re-vendor if the version number hasn't changed #8181

jsgf opened this issue Apr 29, 2020 · 1 comment · Fixed by #14530
Labels
C-bug Category: bug Command-vendor S-triage Status: This issue is waiting on initial triage.

Comments

@jsgf
Copy link
Contributor

jsgf commented Apr 29, 2020

Problem

cargo vendor fails to re-vendor a package if:

  • the package vendor dir has a version number (eg because it's not the most recent, or --versioned-dirs is in use)
  • the code has changed

This can happen if the code is coming from a git repo and the rev has been updated, if a patch has been added in the [patch] section of the Cargo.toml, or when switching between crates.io and git as a source.

This doesn't happen for non-versioned directories because cargo vendor unconditionally re-vendors their contents.

Possible Solution(s)
Rather than just comparing the version, it should also check for changes to the patch and/or origin specification.

Notes

Output of cargo version: 1.42, but this hasn't changed in recent versions

@jsgf jsgf added the C-bug Category: bug label Apr 29, 2020
@epage epage added the S-triage Status: This issue is waiting on initial triage. label Nov 4, 2023
@roblabla
Copy link
Contributor

roblabla commented Apr 8, 2024

I'm affected by this, switching from a git source to a crates.io published version for a previously unpublished crate.

bors added a commit that referenced this issue Sep 13, 2024
fix(vendor): trust crate version only when coming from registries

### What does this PR try to resolve?

Fixes #8181
Relates to #11897 and #14525

### How should we test and review this PR?

As mentioned in the contribution guide, I made a first commit adding a test that passes with the actual behaviour. Then, I made a second commit with a fix and modified the test with the new expected  behaviour.

### Additional information

The fix doesn't take into account switching from a git dependency to crates.io, which is not handled correctly on master either, and would probably require the vendoring to serialize the source ID to detect source changes.

I specifically limited the trust of immutable version to crates.io, but it could be extended to other registries.
@bors bors closed this as completed in d949021 Sep 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug Command-vendor S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants