gazelle handling of sibling imports

[amartani]

Currently, rules_python gazelle seems to treat absolute imports as if they could be resolved as relative imports. This is explicitly tested in the following test case:

https://github.com/bazel-contrib/rules_python/tree/cbe6d38d01c14de46d90ea717d0f2090117533fa/gazelle/python/testdata/sibling_imports

In this test case, pkg/unit_test.py has import a, and that gets resolved to pkg/a.py (which then results in :pkg being added to deps). This seems like a bug to me, given that these files are not in the repo root, nor pkg/BUILD.in has the python_root directive, and therefore, python will not resolve the absolute import to the sibling file. If you recreate the same repository layout from this test case and run bazel test //pkg:unit_test, the test fails with the import failing.

For context - I'm trying to adopt gazelle in an existing codebase that has a number of internal modules with the same name as public libraries (eg. a typing.py file with some internal type annotation, or some files that have the same name as a top-level project), and, in these cases, gazelle is resolving to the wrong library (ie. to the sibling file instead of the third-party or global one). We patched our gazelle to remove this behavior.

My main questions are:

• Is this a bug, or is there a scenario where this behavior is actually useful? The only case that I can think of is if you actually run it outside of bazel (ie. running python pkg/unit_test.py directly, which adds pkg to python path), or if you are running python2 (has been long unsupported), but neither seem plausible... Any other case that I'm missing?
• Can I send a PR to remove this behavior? Possibly guarded by a directive?