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 should vendor crates in a pristine state #15090

Open
glandium opened this issue Jan 22, 2025 · 4 comments
Open

cargo vendor should vendor crates in a pristine state #15090

glandium opened this issue Jan 22, 2025 · 4 comments
Labels
Command-vendor S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review

Comments

@glandium
Copy link
Contributor

In a large project, where different people might run cargo vendor with different versions of cargo, it would be better to avoid the unwanted noise from each version of cargo introducing changes to the cargo publish output.

Things were mostly fine until cargo 1.80, but since then almost each and every release of cargo has introduced changes that introduces churn on Cargo.toml, Cargo.lock and consequently .cargo-checksum.json.

Things like issue #14965 also wouldn't happen if the vendored crates were unmodified.

@epage
Copy link
Contributor

epage commented Jan 22, 2025

This is a more general form of several issues we already have. Copying #15080 (comment)

Thanks for the report!

We have a number of cargo vendor issues related to it not replicating the contents of the .crate file because it essentially re-computes the list of files. Because the .crate file is no longer in a git repository, that logic changes (in this case, skipping hidden fiels). #14034 (comment) contains some notes about this (there are several other issues as well, though I don't see any mentioning this particular case).

I don't recall if there are any updates since #12509 (comment) about trying to change that.

@ehuss
Copy link
Contributor

ehuss commented Jan 22, 2025

I'm a little unclear from the report if it is related to that issue, or if it is related to Cargo.toml normalization (which changes from version to version). cargo vendor should not be causing any changes to the three files mentioned.

@glandium Can you give a more detailed description of exactly which commands you are running, and which changes you are identifying between cargo versions?

@ehuss
Copy link
Contributor

ehuss commented Jan 23, 2025

Ah, I did not realize that was happening with cargo vendor. That's not good, and all the more reason to try again to implement a direct extraction.

@ehuss ehuss added the S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review label Jan 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Command-vendor S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review
Projects
None yet
Development

No branches or pull requests

3 participants