fix(gazelle): Correctly resolve deps that have top-level module overlap with a gazelle_python.yaml dep module#2160
Merged
aignas merged 1 commit intobazel-contrib:mainfrom Aug 28, 2024
Conversation
Contributor
Author
ca81c7f to
3a25f13
Compare
3a25f13 to
3804bbb
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
In #2048,
FindThirdPartyDependencywas updated to walk up the module import path to try to find a match in gazelle_python.yaml. This is unnecessary, as the main resolve loop will accomplish the same task.Additionally, the change broke the ability to configure a more specific resolve override or resolve more specific indexed libraries.
For a real-world example of where this is a problem,
pytypehas athird_partymodule at its top-level. In a repo that also has athird_partydirectory, we can no longer resolve our indexed libraries inthird_party. When the resolve loop tried to resolvethird_party.foo.bar,FindThirdPartyDependencywill immediately matchthird_partyand not give the resolve loop a chance to look in the rule index forthird_party.foo.bar.The same issue appears for providing overrides that are more specific (see the updated testcase).
This PR reverts the change to FindThirdPartyDependency and updates the testcases to ensure that we can still resolve specific indexed packages, explicit resolve overrides, and third party modules even when there is an overlap in the top-level module name.