Allow patching dependencies with patch files
### Summary This proposes to add an ability for Cargo to patch dependencies with patch files. ### Problem description The addition of the [patch] manifest section has made making localised changes to crates used by an individual project much easier. However, 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 approach is fairly reasonable for individual Rust projects, however when embedded in a much larger build system that pulls hundreds of various projects together this can quickly become unwieldy (e.g. Buildroot, OpenWrt build system, etc). Rather than storing the entire source for any packages requiring modification, these build system instead store a set of patch files against a specific release version for the package in question. ### Possible solution This proposes adding an ability to let Cargo apply a set of patch files to a create after it is retrieved and extracted and before it is compiled. It would probably make sense to use the unified diff format given its popularity with tools like Git etc. A previous proposal #3830 similar to this one, suggested the following syntax: ```TOML [dependencies.foobar] version = "1.42" patches = [ "path/to/patch-1.patch", "path/to/patch-2/foobarize-a-bit-less.patch" ] ``` That syntax seems like a good starting point although someone with more Cargo experience might have a better idea. ### Final remarks One of the stated 2017 ro
Posted by hetmankp on Oct 20, 2017, 3:55 AM
Tags
Related issues
- struct's lifetime requirements can be bypassed via covariant field assignment
- Proposal to Reorganize the Moderation Team and Review Moderation Policies
- Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
- proposal: container/...: generic collection types
- Better Custom Endpoint BYOK
- A concrete policy for backward compatibility until Godot 5.0
Raise real-world problems, find people facing the same issue, and discuss solutions.4,500 issues0 comments
github (Other)
struct's lifetime requirements can be bypassed via covariant field assignment
Proposal to Reorganize the Moderation Team and Review Moderation Policies
Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
proposal: container/...: generic collection types
Better Custom Endpoint BYOK
A concrete policy for backward compatibility until Godot 5.0
New MTP models not supported
Tracking: 429 / Capacity Issues
Allow patching dependencies with patch files
### Summary This proposes to add an ability for Cargo to patch dependencies with patch files. ### Problem description The addition of the [patch] manifest section has made making localised changes to crates used by an individual project much easier. However, 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 approach is fairly reasonable for individual Rust projects, however when embedded in a much larger build system that pulls hundreds of various projects together this can quickly become unwieldy (e.g. Buildroot, OpenWrt build system, etc). Rather than storing the entire source for any packages requiring modification, these build system instead store a set of patch files against a specific release version for the package in question. ### Possible solution This proposes adding an ability to let Cargo apply a set of patch files to a create after it is retrieved and extracted and before it is compiled. It would probably make sense to use the unified diff format given its popularity with tools like Git etc. A previous proposal #3830 similar to this one, suggested the following syntax: ```TOML [dependencies.foobar] version = "1.42" patches = [ "path/to/patch-1.patch", "path/to/patch-2/foobarize-a-bit-less.patch" ] ``` That syntax seems like a good starting point although someone with more Cargo experience might have a better idea. ### Final remarks One of the stated 2017 ro
Comments (0)
No comments yet. Start the discussion.