-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Description
Somehow, this came to pass:
Personally I don't think that "simply add
[patch]to.cargo/config" is viable. Thepatchtable 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.unusedto all lock files with projects using the configuration.Lock files in existing projects will no longer work because
patch.unusedneeds 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 ifpatchis perhaps overpowered or if a subset ofpatchshould 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.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status