Python package is shadowed when a workspace has same name and is included as local_repository

[EricCousineau-TRI]

Description of the problem:

If a new_local_repository / local_repository is defined in such a way that a Python package shares a common name with the Bazel workspace / repository, then the intended Python package appears to be shadowed by the workspace directory due to the (potentially excessive?) sprinkling of __init__.py files throughout the symlink forest.

If possible, provide a minimal example to reproduce the problem:

See py_nest_repro:

• show_issue.sh - reproduces the issue.
• show_issue.output.txt - example output from my system

This example has a top-level repo, py_nest_repro, which adds a sub-repo, sub_example, which has a Python package at @sub_example//src/sub_example, and a test usage_test.py, which imports sub_example and executes its check() method.
This test is also symlink'd into py_nest_repro, and tested against including the module from an external.

The test works when run directly inside of sub_example, but fails when attempting to run it from py_nest_repro due the shadowing issues.

Environment info

• Operating System:
  Ubuntu 16.04.2 LTS

• Bazel version (output of bazel info release):
  release 0.6.1

Have you found anything relevant by searching the web?

No, nothing in GitHub issues or searching online.

Anything else, information or logs or outputs that would be helpful?

The workaround is to avoid naming your workspace / package the same as your contained Python package (e.g. tensorflow may be able to get around this since the workspace name is org_tensorflow).
However, this seems like it constrains the modularity of the package (since you have to be wary of your package's name and how you use those targets within your project).

[drigz]

I tried the --noexperimental_python_import_all_repositories workaround, but it breaks rules_docker, which imports tools.build_defs.pkg from @bazel_tools.

@damienmg, is that a bug in rules_docker? Should it be using bazel_tools.tools.build_defs.pkg?

[brandjon]

Possibly related: #3925.

[ABK142]

Hello

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen (or ping me to reopen) if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.