-
Notifications
You must be signed in to change notification settings - Fork 559
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resolving sibling modules with absolute imports #1029
Conversation
Ready for review, but the CI is affected by https://github.com/orgs/community/discussions/45830 |
"github.com/bazelbuild/bazel-gazelle/config" | ||
"github.com/bazelbuild/bazel-gazelle/rule" | ||
"github.com/emirpasic/gods/sets/treeset" | ||
godsutils "github.com/emirpasic/gods/utils" | ||
"path/filepath" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unnecessary and wrong change, we keep standard lib imports at the top.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was changed by my GoLand and I didn't notice.
":__test__", | ||
":generated_test_entrypoint", | ||
], | ||
deps = [":__test__"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may be a breaking change.
This reverts commit 9fc7cfa. Signed-off-by: Thulio Ferraz Assis <[email protected]>
Revert "Resolving sibling modules with absolute imports (#1029)" This reverts commit 9fc7cfa. Signed-off-by: Thulio Ferraz Assis <[email protected]>
* Resolving sibling modules with absolute imports * unconditionally importing conftest * handle from statements * adding tests * adding readme for the new test case Signed-off-by: Thulio Ferraz Assis <[email protected]>
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
py_test
andpy_binary
unconditionally depends onpy_library
in the same package. In order to do that, the Gazelle plugin introduce an virtual import to identify thepy_library
target.What is the new behavior?
With the capability of resolving sibling modules introduced in #1027, we can resolve
py_library
as needed inpy_test
andpy_binary
, and we no longer need any virtual imports or id forpy_library
targets. This simplifies the logic.Does this PR introduce a breaking change?
Other information