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

Specification of the "branch = master" in Cargo.toml breaks the build #12128

Closed
iddm opened this issue May 11, 2023 · 2 comments
Closed

Specification of the "branch = master" in Cargo.toml breaks the build #12128

iddm opened this issue May 11, 2023 · 2 comments
Labels
A-git Area: anything dealing with git A-lockfile Area: Cargo.lock issues C-bug Category: bug S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@iddm
Copy link

iddm commented May 11, 2023

Problem

If we have two crates depending on some crate X being a git repository, they should have the dependency:

[dependencies]
x = { git = "<repo>" }

In both crates' Cargo.toml files.
By default, the master branch is taken, according to the documentation.

However, if one crates decides to explicitly mention the branch name, as in

[dependencies]
x = { git = "<repo>", branch = "master" }

Cargo treats these as two different x crates and breaks the symbol compatibility between the two crates: both crates can't work with each other any longer, since they depend on two different crates, even if this is not the case.

In the Cargo.lock file one can observe for the first crate:

[[package]]
name = "first"
version = "0.1.0"
dependencies = [
  "x 99.99.99 (git+https://github.com/x/x?branch=master)",

And for another:

[[package]]
name = "second"
version = "0.1.0"
dependencies = [
 "x 99.99.99 (git+https://github.com/x/x)",

Steps

  1. Create a workspace with two crates, depending on some other crate x.
  2. In the first crate, depend on the crate x using git and don't specify the branch name.
  3. In the second crate, do depend on the crate x using git and specify the branch name.
  4. Observe the problem that even though the crate x is actually the same, as per the documentation, if the branch name is omitted the master is taken, and the actual contents are actually the same, the symbols clash and don't merge, the compatibility breaks between the first and the second crates within the same workspace.

Possible Solution(s)

Either forbid the omission of the branch name or revision or somehow make it work.
Note, that the documentation says that it should work:

Since we haven’t specified any other information, Cargo assumes that we intend to use the latest commit on the main branch to build our package. 

Notes

No response

Version

❯ cargo version --verbose
cargo 1.69.0 (6e9a83356 2023-04-12)
release: 1.69.0
commit-hash: 6e9a83356b70586d4b77613a6b33f9ea067b9cdf
commit-date: 2023-04-12
host: x86_64-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.86.0-DEV (sys:0.4.59+curl-7.86.0 vendored ssl:OpenSSL/1.1.1q)
os: Arch Linux Rolling Release [64-bit]
@iddm iddm added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels May 11, 2023
@weihanglo weihanglo added A-git Area: anything dealing with git S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. A-lockfile Area: Cargo.lock issues and removed S-triage Status: This issue is waiting on initial triage. labels May 11, 2023
@weihanglo
Copy link
Member

Thanks for the report and the reproducer! This seems to share the same root cause with #7497 and #11490. We're also tracking changes that need a lockfile version bump in #12120. Close in favor of those :)

@iddm
Copy link
Author

iddm commented May 11, 2023

Thank you! This indeed looks the same to me as the aforementioned issues, but I can't be exactly sure in that as I don't know the code of cargo and which code paths it takes in all the scenarios. If you are sure it is the same, we can close this issue, no problem! Have a great day!

@weihanglo weihanglo closed this as not planned Won't fix, can't repro, duplicate, stale May 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-git Area: anything dealing with git A-lockfile Area: Cargo.lock issues C-bug Category: bug S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

2 participants