Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, when a dependency tree contained multiple versions of the same dependency we used the following rules to resolve the conflicts:
There are a few problems with these rules:
I'd say the first problem is the most important one, as it makes it impossible to work around other.
This PR implements an alternative conflict resolution strategy — the dependencies nearest to the root win. This is, for example, similar to what Maven does. This makes it trivial to override any dependency by explicitly specifying the revision in the
protofetch.toml
.Besides making version resolution more flexible (which I suppose is rarely a problem in practice, as dependency trees are usually relatively small), there is a second reason why I'd like to make this change. With the current rules, transitive dependencies affect the dependency resolution but are not recorded in the lock file, so while the lock file stores the resulting revisions, it is impossible to verify that the lock file corresponds to
protofetch.toml
. An alternative solution could be to write all transitive dependencies in the lock file, even if they are not a part of the final dependency set. This is however not backwards compatible, and in my opinion it'd be nice to changing the resolution strategy anyway.