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

Patching dependencies does not work if it's for the same location but a different branch #5478

Open
sdroege opened this issue May 4, 2018 · 22 comments
Labels
A-patch Area: [patch] table override 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

@sdroege
Copy link
Contributor

sdroege commented May 4, 2018

E.g.

[patch.'https://github.com/sdroege/gobject-subclass']
gobject-subclass = { git = 'https://github.com/sdroege/gobject-subclass', branch = 'refactoring' }

This gives

error: failed to resolve patches for `https://github.com/sdroege/gobject-subclass`

Caused by:
  patch for `gobject-subclass` in `https://github.com/sdroege/gobject-subclass` points to the same source, but patches must point to different sources
@alexcrichton
Copy link
Member

Ah yeah this is sort of an unfortunate side-effect of the implementation of patch in that it only looks at URLs, not at the full source. That is, you can't even say you only want to replace the source where the branch is master, instead a [patch] applies to all git sources with the same url (regardless of rev/branch/etc). That means that this is currently replacing itself as well, which is disallowed.

@jplatte
Copy link
Contributor

jplatte commented Aug 4, 2019

For GitHub repositories, one can work around this by [patch]ing https://github.com/user/repo to https://github.com/user/repo.git (or the other way around).

@est31
Copy link
Member

est31 commented Aug 19, 2019

For GitHub repositories, one can work around this by [patch]ing https://github.com/user/repo to https://github.com/user/repo.git (or the other way around).

Nice workaround hack! Further ways to change the URL string include adding / to the url like https://github.com////user///repo . This method scales to unlimited amounts of different urls for the same repo.

@brenzi
Copy link

brenzi commented Oct 7, 2019

The above workaround doesn't work for us, because what we patch has dependencies as well which need to be patched by the workspace patch. However, as the url now changed, it won't be patched.
I thought I could just add another level of patching:

[patch.'https://github.com/scs/substrate']
primitives = { git = "https://github.com/scs//substrate", package = 'substrate-primitives', tag = "substraTEE-M5.1" }

[patch.'https://github.com/scs//substrate']
primitives = { git = "https://github.com/scs///substrate", package = 'substrate-primitives', tag = "substraTEE-M5.1" }

but that won't work:

cargo update
    Updating git repository `https://github.com/scs/ed25519-dalek.git`
    Updating git repository `https://github.com/scs///substrate`
warning: spurious network error (2 tries remaining): unexpected HTTP status code: 404; class=Net (12)
warning: spurious network error (1 tries remaining): unexpected HTTP status code: 404; class=Net (12)
error: failed to resolve patches for `https://github.com/scs//substrate`

Caused by:
  failed to load source for a dependency on `substrate-primitives`

Caused by:
  Unable to update https://github.com/scs///substrate?tag=substraTEE-M5.1

Caused by:
  failed to fetch into /home/abrenzikofer/.cargo/git/db/substrate-df78ab1b7ea0c505

Caused by:
  unexpected HTTP status code: 404; class=Net (12)

also linking it back to the original url won't work:

[patch.'https://github.com/scs/substrate']
primitives = { git = "https://github.com/scs//substrate", package = 'substrate-primitives', tag = "substraTEE-M5.1" }

[patch.'https://github.com/scs//substrate']
primitives = { git = "https://github.com/scs/substrate", package = 'substrate-primitives', tag = "substraTEE-M5.1" }

because:


thread 'main' panicked at 'assertion failed: prev.is_none()', src/tools/cargo/src/cargo/core/resolver/context.rs:153:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

@brenzi
Copy link

brenzi commented Oct 7, 2019

this bug has been open for a long time. is there hope? we're stuck with a suboptimal setup due to this.

@sjackman
Copy link

Any progress on this issue?

@brenzi
Copy link

brenzi commented Oct 30, 2019

this could IMO be fixed by #7497

@Diggsey
Copy link
Contributor

Diggsey commented Nov 23, 2020

I've definitely been confused by this because I didn't understand how the [patch] syntax for git repos could work without specifying a branch... Now that I've seen this bug it makes sense.

@sblackshear
Copy link

For GitHub repositories, one can work around this by [patch]ing https://github.com/user/repo to https://github.com/user/repo.git (or the other way around).

Nice workaround hack! Further ways to change the URL string include adding / to the url like https://github.com////user///repo . This method scales to unlimited amounts of different urls for the same repo.

These workarounds no longer do it for me (using cargo 1.52.0)--perhaps Cargo is now normalizing repo names?

@janhohenheim
Copy link

janhohenheim commented May 14, 2022

@est31 FYI that hack seems to ignore rev patches for some reason.
I came up with a new hack based on this issue. I think appending /tree/<branch> to the URL should do the trick.

rrbutani added a commit to ut-utp/tm4c-previous that referenced this issue May 28, 2022
Because of a change in how Cargo normalizes dependency URLs, we are now
unable to change the `ut-utp/core` branch that this crate depends On
from a dependent. Our old lock files from May of 2020 were also no help
because they referred to branches that have since been merged and
deleted.

So, just to get unstuck while we work on newer more robust peripheral
implementations, we're taking the `feat-non-generic` branch as it was
in May of 2020 and changing it to use the latest `ut-utp/core` from
`master`.

See: rust-lang/cargo#5478 (comment)
rrbutani added a commit to ut-utp/tm4c-previous that referenced this issue May 28, 2022
Because of a change in how Cargo normalizes dependency URLs, we are now
unable to change the `ut-utp/core` branch that this crate depends On
from a dependent. Our old lock files from May of 2020 were also no help
because they referred to branches that have since been merged and
deleted.

So, just to get unstuck while we work on newer more robust peripheral
implementations, we're taking the `feat-non-generic` branch as it was
in May of 2020 and changing it to use the latest `ut-utp/core` from
`master`.

See: rust-lang/cargo#5478 (comment)
@Diggsey
Copy link
Contributor

Diggsey commented Jun 30, 2022

If anyone is having trouble with overriding SSH URLs, and can't use HTTPS for whatever reason (eg. private git repo) I found another workaround is to add the port number to the URL, like ssh://git@github.com:22/<org>/<repo>.git

@haythemsellami
Copy link

haythemsellami commented Feb 25, 2023

Have you tried this:

ethers-rs = { git = "https://github.com/gakonst////ethers-rs.git", branch = "test" }

The canonicalization code only strips trailing / and .git. For extra / inside the URL, it doesn't do anything.

I think this workaround fails with Cargo v, I did find another one:

ethers-rs = { git = "https://github.com:443/gakonst/ethers-rs.git?rev=test", branch = "test" }

@Skgland

This comment was marked as off-topic.

@jplatte
Copy link
Contributor

jplatte commented Mar 20, 2023

I think that's sufficiently different to have its own GitHub issue.

@Skgland
Copy link

Skgland commented Mar 20, 2023

Ah, I think my problem is already covered by #9227

bors bot added a commit to godot-rust/gdext that referenced this issue Apr 2, 2023
211: Prebuilt Godot artifacts r=Bromeon a=Bromeon

Closes #12 
Closes #107 

From now on, gdext by default fetches pre-generated versions of these files, published in the [`godot4-prebuilt`](https://github.com/godot-rust/godot4-prebuilt) repo:
* `extension_api.json` (from Godot binary)
* `gdextension_interface.h` (from Godot binary)
* `gdextension_interface.rs` (through bindgen -- currently supports 3 platforms)

This has several benefits:
1. Significantly fewer dependencies, as bindgen is no longer needed, and thus smaller compile times.
2. Most CI jobs no longer need the Godot binary (clippy, test), speeding up CI _in addition_ to (1).
3. It's possible to change the Godot API behind gdext without manually rebuilding the artifacts.
4. Easy comparison between the Godot APIs of different released versions.


### Using a custom Godot binary

It is still possible to generate those files locally like before, through the use of the `custom-godot` feature on the `godot` crate.

This is necessary for any platform/configuration different from the 3 main supported ones (because bindgen generates different Rust bindings), as well as any in-development or modified Godot versions.


### Changing the Godot release

By default, the latest Godot release is used as input to gdext. Switching between different Godot versions is easily possible, although a bit cumbersome.

If you want to use an older version `4.0`, add this to your **workspace** (not sub-crate) `Cargo.toml`:
```toml
# We need to trick Cargo into seeing a different URL; rust-lang/cargo#5478
[patch."https://github.com/godot-rust/godot4-prebuilt"]
godot4-prebuilt = { git = "https://github.com//godot-rust/godot4-prebuilt", branch = "4.0"}
```
We're looking into ways to simplify this. In a crates.io release (#2), we would need to rethink this anyway, mapping Godot versions to Rust release versions (which is not trivial).

Co-authored-by: Jan Haller <bromeon@gmail.com>
@boyswan
Copy link

boyswan commented Apr 12, 2023

This worked for me (www and .git) :

[patch.'https://github.com/foo/bar']
baz = { git = "https://www.github.com/foo/bar.git", branch = "test" }

@metasim
Copy link

metasim commented Nov 4, 2024

Conversation on prerequisites to addressing this issue: https://internals.rust-lang.org/t/how-to-assist-with-bug-5478/21819/1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-patch Area: [patch] table override 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