Idea: patch-sets in Cargo

tools and infrastructure cargo
1

Assuming that the following is true:

  1. Custom Registries are intended to augment dependencies, not to replace. Practically speaking, they don't trickle down to an application's sub-dependencies. For example, if I have a custom registry with a fork of some popular crate, and a dependency in my application also depends on that crate, the custom registry approach will successfully patch the direct usage in my application, but not the usage in the dependency code. I'm not entirely sure about this - can someone please confirm?

  2. Patches are intended for single crates, and mostly for development purposes.

This means that it's quite hard to point at forks of multiple, related crates.

It would be nice to have a patch-set that worked as something like a blend between custom registries and patches. Namely, that I can point at a single manifest, and that manifest will patch all its listed crates - whether they are used in my application or one of my application's dependencies.

I believe Nix Overlays or Purescript's package sets might be similar, and there was an earlier discussion of this here: Pre-RFC: Support package sets in cargo

The syntax could be very simple. Roughly, something like:

patches = 'https://github.com/example/patches.toml'

and then patches.toml would just describe all the crates it's patching:

foo = { git = 'https://github.com/example/patched-foo'}
bar = { git = 'https://github.com/example/patched-bar'}

In the case of multiple patch-sets that conflict, I'd suggest an order of overrides, so that a crate in example2 would be used in the case of it existing both there and example1:

patches = [
    'https://github.com/example1/patches.toml', 
    'https://github.com/example2/patches.toml'
]

Fwiw, even if the initial question about registries is misguided, it can be tricky to setup a custom registry and the multi-patch approach with simple toml might be a welcome addition to make it easier in the use case described here.

Since this is currently at a "do I understand this right" sort of stage, I've labelled it as Idea instead of Pre-RFC. Happy to change the title if it merits.

2

If you have a set of crates that all the need the same patches, why not collect them in a single workspace?

3

The idea here is more about inverting the responsibility so that the patch-set maintainer decides where to pull the crates from, and then various applications can just point to that patch-set

So for example, there's a lot of crates in the rustwasm ecosystem (wasm-bindgen, web-sys, js-sys, gloo-*, wasm-pack, etc.)

Let's say somebody decided to maintain a fork of a few of those (e.g. gloo-events, gloo-timers, and wasm-pack).

That maintainer would be able to publish a patch-set, and then application developers can simply point at that patch-set and know that they are getting the maintainer's idea of the most up-to-date version of those specific crates.

This would be doable even if these forks weren't published to crates.io (the maintainer's patch-set could point to the git repos)

If it were only for one application developer, sure, they could just list all the patches and make it easier to share between local crates in a workspace. The problem is making it easier to share this configuration between the community at large.

4

This topic was automatically closed 540 days after the last reply. New replies are no longer allowed.