-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Description
Somehow, this came to pass:
Personally I don't think that "simply add
[patch]
to.cargo/config
" is viable. Thepatch
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 ifpatch
is perhaps overpowered or if a subset ofpatch
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.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status