Warn about path overrides that won't work #3136
Conversation
Cargo has a long-standing [bug] in path overrides where they will cause spurious rebuilds of crates in the crate graph. This can be very difficult to diagnose and be incredibly frustrating as well. Unfortunately, though, it's behavior that fundamentally can't be fixed in Cargo. The crux of the problem happens when a `path` replacement changes something about the list of dependencies of the crate that it's replacing. This alteration to the list of dependencies *cannot be tracked by Cargo* as the lock file was previously emitted. In the best case this ends up causing random recompiles. In the worst case it cause infinite registry updates that always result in recompiles. A solution to this intention, changing the dependency graph of an overridden dependency, was [implemented] with the `[replace]` feature in Cargo awhile back. With that in mind, this commit implements a *warning* whenever a bad dependency replacement is detected. The message here is pretty wordy, but it's intended to convey that you should switch to using `[replace]` for a more robust impelmentation, and it can also give security to anyone using `path` overrides that if they get past this warning everything should work as intended. [bug]: rust-lang#2041 [implemented]: http://doc.crates.io/specifying-dependencies.html#overriding-dependencies Closes rust-lang#2041
|
@alexcrichton: no appropriate reviewer found, use r? to override |
|
r? @brson |
|
|
||
| To change the dependency graph via an override it's recommended to use the | ||
| `[replace]` feature of Cargo instead of the path override feature. This is | ||
| documented online at the url below for more information. |
There was a problem hiding this comment.
I'm not sure [replace] handles all the secenarios that path overrides do. In particular, Servo and Gecko seem to get hit by some of the version constraints around [replace] that AFAIK do not exist for path.
There was a problem hiding this comment.
@larsbergstrom if that's the case then that's definitely a bug in [replace], are there open issues for this?
Additionally paths isn't going away, this is just warning about a case where it will never work (e.g. you replace with something that changed dependencies)
There was a problem hiding this comment.
Aha, great! That sounds fine, then :-)
We have open issues (e.g., #2649), but I think that's more of a separate discussion than something that should derail this PR!
There was a problem hiding this comment.
Also feel free to ping me periodically about those kinds of issues if they keep coming up, it's good to always confirm or deny initial assumptions!
|
@bors r+ |
|
|
Warn about path overrides that won't work Cargo has a long-standing [bug] in path overrides where they will cause spurious rebuilds of crates in the crate graph. This can be very difficult to diagnose and be incredibly frustrating as well. Unfortunately, though, it's behavior that fundamentally can't be fixed in Cargo. The crux of the problem happens when a `path` replacement changes something about the list of dependencies of the crate that it's replacing. This alteration to the list of dependencies *cannot be tracked by Cargo* as the lock file was previously emitted. In the best case this ends up causing random recompiles. In the worst case it cause infinite registry updates that always result in recompiles. A solution to this intention, changing the dependency graph of an overridden dependency, was [implemented] with the `[replace]` feature in Cargo awhile back. With that in mind, this commit implements a *warning* whenever a bad dependency replacement is detected. The message here is pretty wordy, but it's intended to convey that you should switch to using `[replace]` for a more robust impelmentation, and it can also give security to anyone using `path` overrides that if they get past this warning everything should work as intended. [bug]: #2041 [implemented]: http://doc.crates.io/specifying-dependencies.html#overriding-dependencies Closes #2041
|
|
Cargo has a long-standing bug in path overrides where they will cause spurious
rebuilds of crates in the crate graph. This can be very difficult to diagnose
and be incredibly frustrating as well. Unfortunately, though, it's behavior that
fundamentally can't be fixed in Cargo.
The crux of the problem happens when a
pathreplacement changes somethingabout the list of dependencies of the crate that it's replacing. This alteration
to the list of dependencies cannot be tracked by Cargo as the lock file was
previously emitted. In the best case this ends up causing random recompiles. In
the worst case it cause infinite registry updates that always result in
recompiles.
A solution to this intention, changing the dependency graph of an overridden
dependency, was implemented with the
[replace]feature in Cargo awhile back.With that in mind, this commit implements a warning whenever a bad dependency
replacement is detected. The message here is pretty wordy, but it's intended to
convey that you should switch to using
[replace]for a more robustimpelmentation, and it can also give security to anyone using
pathoverridesthat if they get past this warning everything should work as intended.
Closes #2041