itmettkeDE / cargo-patch

Cargo Subcommand for patching dependencies using patch files
MIT License
66 stars 8 forks source link

Patches do not apply before `cargo update` #61

Open ambasta opened 9 months ago

ambasta commented 9 months ago

I am adding feature flags to dependencies that my package depends on. These features are enabled/disabled depending on the features exposed by my package itself.

However, on cargo update, the dependencies fail to resolve, since the dependency itself doesn't expose said feature flags.

Not sure what should be the ideal flow here.

mettke commented 9 months ago

Can you give me more information about your setup like a minimal Cargo.toml that reproduces the problem? Otherwise its hard for me to fully grasp what you are trying to do.

ambasta commented 9 months ago

Sure,

Consider the following patch to aperture, which adds feature flags to it

From 8324348c744987da68cc7cc1a2ca5f6a292ff8cd Mon Sep 17 00:00:00 2001
From: Amit Prakash Ambasta <amit.prakash.ambasta@gmail.com>
Date: Fri, 3 Nov 2023 14:02:02 +0530
Subject: [PATCH] feature patch

Signed-off-by: Amit Prakash Ambasta <amit.prakash.ambasta@gmail.com>
---
 Cargo.toml      | 16 +++++++++++-----
 Cargo.toml.orig |  8 +++++++-
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/Cargo.toml b/Cargo.toml
index 40210a4..e960738 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -42,11 +42,7 @@ package = "gstreamer-pbutils"

 [dependencies.gst-plugin-gtk4]
 version = "0.11"
-features = [
-    "wayland",
-    "x11egl",
-    "x11glx",
-]
+default-features = false

 [dependencies.gst-video]
 version = "0.21"
@@ -62,3 +58,13 @@ version = "0.4.17"

 [dependencies.once_cell]
 version = "1.17.1"
+
+[features]
+default = [
+    "wayland",
+    "x11egl",
+    "x11glx",
+]
+wayland = ["gst-plugin-gtk4/wayland"]
+x11egl = ["gst-plugin-gtk4/x11egl"]
+x11glx = ["gst-plugin-gtk4/x11glx"]
diff --git a/Cargo.toml.orig b/Cargo.toml.orig
index e10f45c..5f144d5 100644
--- a/Cargo.toml.orig
+++ b/Cargo.toml.orig
@@ -11,10 +11,16 @@ documentation = "https://gnome.pages.gitlab.gnome.org/snapshot/doc/aperture"
 version = "0.3.2"
 rust-version = "1.70"

+[features]
+default = ["wayland", "x11egl", "x11glx"]
+wayland = ["gst-plugin-gtk4/wayland"]
+x11egl = ["gst-plugin-gtk4/x11egl"]
+x11glx = ["gst-plugin-gtk4/x11glx"]
+
 [dependencies]
 gst = { package = "gstreamer", version = "0.21", features = ["v1_20"] }
 gst-pbutils = { package = "gstreamer-pbutils", version = "0.21" }
-gst-plugin-gtk4 = { version = "0.11", features = ["wayland", "x11egl", "x11glx"] }
+gst-plugin-gtk4 = { version = "0.11", default-features = false }
 gst-video = { package = "gstreamer-video", version = "0.21" }
 gtk = { package = "gtk4", version = "0.7", features = ["gnome_45"] }
 log = "0.4.17"
-- 
2.42.0

We use this patched aperture in our own crate as

...
[features]
default = ["wayland"]
wayland = ["aperture/wayland"]
x11 = ["aperture/x11egl", "aperture/x11glx"]

[dependencies]
aperture = {package = "aperture", version ="0.3.2", default-features = false}
...

At this point, invoking cargo update will fail due to being unable to satisfy the dependecy aperture, with the feature flags we want to add via the patch.

mettke commented 9 months ago

Hm... ok that is strange and at the moment I cannot really see the problem. This should work without any problems.

Just two more things to make sure those are not the problem. I assume you did setup the patching using something like this in your Cargo.toml:

[package.metadata.patch.aperture]
version = "0.3.2"
patches = [
    "<path-to-aperture-patch-file>"
]

Afterwards you ran cargo patch and then you added something like this to your Cargo.toml:

[patch.crates-io]
aperture = { path = './target/patch/aperture-0.3.2' }
ambasta commented 9 months ago
mettke commented 9 months ago

Good to know that you are using build.rs. But even though you do you still need those two entries.

If you did setup your patching according to the documentation then the build.rs only calls the patch binary. The binary needs those two entries in the Cargo.toml otherwise it does not not where the patch is and it will not replace the dependency with the patched one.

Therefore please check whether the [patch.crates-io]/[package.metadata.patch.apterture] entries are correctly setup. If your build.rs is different then what is documented then please go ahead and post it here so that I can take a look