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]: #2041 [implemented]: http://doc.crates.io/specifying-dependencies.html#overriding-dependencies Closes #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. |
larsbergstrom
Oct 5, 2016
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
.
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
.
alexcrichton
Oct 5, 2016
Author
Member
@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)
@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)
larsbergstrom
Oct 5, 2016
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!
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!
alexcrichton
Oct 5, 2016
Author
Member
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!
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
|
This comment has been minimized.
This comment has been minimized.
Is there an equivalent to |
This comment has been minimized.
This comment has been minimized.
@sgrif not currently, no, unfortunately. If there's a workflow to be had here though (one that works), then we can work on developing it though! (note that it may also be the case that this warning is being emitted in error) |
This comment has been minimized.
This comment has been minimized.
diesel-rs/diesel@78080f0 has the change we had to make. Basically we just want to make sure that all of our test suites run against the in-tree version of everything. Using |
This comment has been minimized.
This comment has been minimized.
Oh that's actually more correct! The |
This comment has been minimized.
This comment has been minimized.
Er, actually, how come |
This comment has been minimized.
This comment has been minimized.
Because after the 20th time a bug slipped in because I forgot to point to point something at a path dependency, it felt like a repo-wide override made much more sense. The alternative is just a lot of git churn and room for mistakes. |
This comment has been minimized.
This comment has been minimized.
If everything is a path dependency always though, would there still be things forgotten? |
This comment has been minimized.
This comment has been minimized.
No, the same version requirement worked out really well as a default for
local development.
…On Mon, Oct 10, 2016, 7:51 PM Alex Crichton ***@***.*** wrote:
If everything is a path dependency always though, would there still be
things forgotten?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
fc0e642#commitcomment-19370599,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABdWK_0fOykpaTST1kcWHwzYDrsq3AtMks5qys-CgaJpZM4KSn4P
.
|
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 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
path
overridesthat if they get past this warning everything should work as intended.
Closes #2041