Add ability to dynamically patch a dependency

[Luthaf]

Say I have a (list of) patch I want to apply to one of the dependencies of my crate, but I can not have it merged upstream. It would be good if cargo could apply the patch at build time on this crate.

[dependencies.foobar]
version = "1.42"
patches = [
    "path/to/patch-1.patch",
    "path/to/patch-2/foobarize-a-bit-less.patch"
]

This feature would be useful in the following cases:

• The maintainer of some crate is not responding but I need to ship my fix quickly;
• I am working in a corporate environment, and I need to patch one of my dependencies, but I can not release this patch;
• I want to tune some crate for my specific use case, but there is no way the crate maintainer can accept my patch, and I do not want to fork the crate just for this.

How this could work

The patch would only be accepted in the unified diff format, at a fixed directory level. At build time, cargo would unpack the crate sources, parse the diff and apply it to the source before proceeding with compilation.

Are there any drawback of doing this I did not though of?

[steveklabnik]

We already have [replace] for this, no?

[Luthaf]

Yes, [replace] could work, but it is a bit less ergonomic: I have to pull the whole crate source somewhere (be it in tree or on github) and leave it available there until no one is using the replacement anymore.

Also, the documentation for it looks like you need to put something on git/github to use replace. I did not though of trying this with a path dependency before your message 😄

[alexcrichton]

Yes this is the intended use case of [replace] currently, but one part we've always wanted is a convenient command like cargo fork which easily applies a [replace] and checks it out locally for you to use!

We already have a feature for this, though, so I'm going to close this. Let me know if it doesn't work though!

[hetmankp]

I'd like to see this issue reopened. While we do now have the [patch] manifest section, this still requires checking out the source code for the entire crate even if only a few lines of the source actually need to be modified.

This seems reasonable for individual Rust projects, however when embedded in much larger build systems that pull hundreds of packages together (e.g. buildroot, openwrt, etc) this quickly becomes unwieldy; each package could represent its own Rust project. What these build systems do is that rather than storing the entire source code for every package they modify, they only store a patch set against a specific release version for each package.

I think this would definitely help with the 2017 roadmap goal of better integration with large build systems.

I'm not sure if I should be posting this here or if I should open an new issue to open the discussion on this again but I'd love to hear some feedback.

[alexcrichton]

@hetmankp it's probably best to open a new issue at this point explaining why this is needed and why [patch] doesn't work