Programatic Patching

[raphaelhetzel]

Problem

Hey,
in my project I am using cargo as a library to build customized binaries (user-generated packages) on a server that are then sent to worker nodes.
For this I need to patch a set of my own API/ABI crates to a local/pinned version.

This can be done using the [patch] section in cargo.toml. However, it would be beneficial to do that programatically. A cargo::core::Workspace allows to acquire a PackageRegistry, which allows applying patches. However, there is no method that allows passing that PackageRegistry back to the Workspaceor to pass it to cargo::ops::compile.

Is there something that makes this impossible?
If I create a PR, which of the options below would be the desired one?

Proposed Solution

I see a few options:

1. A setter that allows setting a PackageRegistry for the Workspace. As the Workspace does not store a PackageRegistry, this might be a larger change.
2. A setter for the workspace's root_patch. While this is also not stored but generated on the fly, I would assume one could add a setter and a hashmap that is merged in with the highest priority.
3. Allow passing the PackageRegistry to cargo::ops::Compile, and pass that through to the resolver.

Notes

No response

[weihanglo]

Thanks for the proposal.

Is there something that makes this impossible?
If I create a PR, which of the options below would be the desired one?

Sorry I don't want to turn you down, but also don't want to give any wrong impression that cargo API is a thing you can rely on without burden. Cargo the library is primarily for use by Cargo the executable and not intended for external use, and there is no guarantee whether the added new API will stay any longer time. These are intentional artifacts for external use, but cargo lib isn't one of them.

Also, I am not sure which option is better, as Cargo uses none of them. Sometimes if a refactor makes things clearer and more manageable, it might be accepted.

Not sure how your workflow really looks like but I assume you can generate a GlobalContext on the fly and configure it with some --config value with either path to a config.toml file, or a config value of a patch.