Patches in ~/.cargo/config.toml add [[patch.unused]] to Cargo.lock

[SamB]

Somehow, this came to pass:

Personally I don't think that "simply add [patch] to .cargo/config" is viable. The patch table was designed to be in manifests, and having it be in global configuration radically changes the feature and breaks some of the design of the feature in the first place:

• Configuration would now add patch.unused to all lock files with projects using the configuration.

• Lock files in existing projects will no longer work because patch.unused needs to be inserted.

• The same issue I mentioned before where when you check something in it may not work elsewhere. (Note that source replacement is not an exception to this rule, source replacement is heavily documented as "you must reflect the contents of the original source", so if you get a lock file you can't use elsewhere then you're mis-using the source replacement feature)

Resolving a dependency graph is intended to be a project-local decision, not a global system-configuration decision. That's sort of what Cargo has always trended towards.

All that being said there may still be room for a patch-like feature to get added to .cargo/config.toml. I think it would be good to enumerate requirements to see if patch is perhaps overpowered or if a subset of patch should be allowed in .cargo/config.toml

Originally posted by @alexcrichton in #5539

I encountered the issue by creating a ~/.cargo/config.toml as shown in FillZpp/sys-info-rs#118 (comment), and then at some point something tried to do a cargo install with --locked, which failed for the reasons quoted above.

[epage]

Could you provide more context for your use case? For your cargo install command, do you need the patch? If so, why? Do you need --locked and, if so, why?

What I'm wanting to weigh is the impact and scope of this. In that linked comment, the alternative was to not support the feature at all.