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

Document that package can be used in [patch] #7263

Merged
merged 1 commit into from
Aug 27, 2019

Conversation

alexcrichton
Copy link
Member

This works to [patch] multiple versions of a crate, and turns out this
has worked since the inception of package!

Closes #6169

@rust-highfive
Copy link

r? @ehuss

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 19, 2019
@ehuss
Copy link
Contributor

ehuss commented Aug 19, 2019

Heh, I stumbled on an issue (#7264).

I'm thinking it might be helpful to add a note expanding on this a little, since I don't think it is obvious how this works. I think there are two points to make:

  • When using the package key, the aliased name on the left doesn't really matter. It is not used to correlate with actual dependency names.
  • Each entry should point to a source with a different version in its Cargo.toml.

(Not sure how to say these two things succinctly and clearly.)

The second point is complex. I would like to at some point add an entire chapter on how version resolution works. When we do that, we can maybe include a dedicated sub-section on how [patch] affects things. For now, I think a brief sentence is fine, we can link it later.

Some of the complexities I'm thinking of are:

  • The two patches should have versions that are semver-incompatible. (This is not entirely correct, it only really applies to caret requirements. It's hard to express in a simple way.)
  • You can't selectively change a semver-incompatible version requirement. That is, you can't patch a dependency of "^0.9" to something that defines "1.0.0".
  • If the patched version is older than what is available, it won't match if it is not already locked. That is, if you patch to a source that defines "1.0.1", but crates.io has "1.0.2", and you don't have a Cargo.lock then the patch won't work. But it will work if Cargo.lock is locked to 1.0.1.

Copy link

@Hoverbear Hoverbear left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rest LGTM. Great digging @alexcrichton !

src/doc/src/reference/manifest.md Outdated Show resolved Hide resolved
@alexcrichton
Copy link
Member Author

@Hoverbear I think you're running into #5478, although it may be manifesting as a panic. I suspect if the panic is fixed then it still won't work due to #5478.

@ehuss excellent points! I think you're definitely right in that we're about 4 years late for having a section on how the resolver works in the documentation. I'll think on this and see if I can figure out a better set of words to include.

@Hoverbear
Copy link

@alexcrichton Ha! Seems this leads down the rabbit hole to #6921 and #5471 :-P

@alexcrichton
Copy link
Member Author

Ok I've touched up some wording and such and spawned off #7301 for more comprehensive documentation about how [patch] and the resolver interact. @ehuss want to take another look?

This works to `[patch]` multiple versions of a crate, and turns out this
has worked since the inception of `package`!

Closes rust-lang#6169
@alexcrichton
Copy link
Member Author

Er I messed up git and didn't actually push, pushed now.

@ehuss
Copy link
Contributor

ehuss commented Aug 27, 2019

@bors r+

@bors
Copy link
Collaborator

bors commented Aug 27, 2019

📌 Commit 2a391a7 has been approved by ehuss

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 27, 2019
@bors
Copy link
Collaborator

bors commented Aug 27, 2019

⌛ Testing commit 2a391a7 with merge 5947fb8...

bors added a commit that referenced this pull request Aug 27, 2019
Document that `package` can be used in `[patch]`

This works to `[patch]` multiple versions of a crate, and turns out this
has worked since the inception of `package`!

Closes #6169
@bors
Copy link
Collaborator

bors commented Aug 27, 2019

☀️ Test successful - checks-azure
Approved by: ehuss
Pushing 5947fb8 to master...

@bors bors merged commit 2a391a7 into rust-lang:master Aug 27, 2019
bors added a commit to rust-lang/rust that referenced this pull request Aug 27, 2019
Update cargo

Update cargo

10 commits in 3f700ec43ce72305eb5315cfc710681f3469d4b4..22f7dd0495cd72ce2082d318d5a9b4dccb9c5b8c
2019-08-19 22:43:12 +0000 to 2019-08-27 16:10:51 +0000
- Update and improve zsh completion (rust-lang/cargo#7296)
- Document that `package` can be used in `[patch]` (rust-lang/cargo#7263)
- Fix `error:`/`warning:` coloring inconsistency with rustc (rust-lang/cargo#7294)
- Tests: Import rustc_plugin from its new location (rust-lang/cargo#7287)
- Update README azure badge. (rust-lang/cargo#7293)
- Update home dependencies to v0.5 (rust-lang/cargo#7277)
- Fix typo (rust-lang/cargo#7279)
- Update libgit2 dependencies (rust-lang/cargo#7275)
- Fix old lockfile encoding wrt newlines (rust-lang/cargo#7262)
- Fix dSYM uplifting when symlink is broken (rust-lang/cargo#7268)
@alexcrichton alexcrichton deleted the multipass branch September 16, 2019 18:25
@ehuss ehuss added this to the 1.39.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

No way to [patch] out multiple versions of a crate
5 participants