Skip to content
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

__init__.py still created, despite --incompatible_default_to_explicit_init_py #12238

Closed
staalb opened this issue Oct 9, 2020 · 1 comment
Closed
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-Python Native rules for Python type: bug

Comments

@staalb
Copy link

staalb commented Oct 9, 2020

Description of the problem / feature request:

When --incompatible_default_to_explicit_init_py is passed, no __init__.py files are created for a py_binary target. However, when that target is used in a genrule, still the __init__.py files are created.

Feature requests: what underlying problem are you trying to solve with this feature?

I have a code generator written in Python, which depends on third party code which uses python namespace packages.

Invoking the py_binary target of the code generator works fine (provided that --incompatible_default_to_explicit_init_py is passed to Bazel). Using this target as a tool in a genrule or with ctx.actions.run fails because Bazel still creates __init__.py files in that case.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Consider the following BUILD file:

py_library(
    name = "lib1",
    srcs = glob(["pylib1/**/*.py"]),
    imports = ["pylib1"],
)

py_library(
    name = "lib2",
    srcs = glob(["pylib2/**/*.py"]),
    imports = ["pylib2"],
)

py_binary(
    name = "test",
    srcs = ["test.py"],
    deps = [":lib1", ":lib2"],
)

genrule(
    name = "gen",
    outs = ["out.txt"],
    cmd = "$(location :test)",
    tools = [":test"],
)

And test.py:

import foo.bar.a
import foo.bar.b

Furthermore, the following empty files exist:

  • WORKSPACE
  • pylib1/foo/bar/a.py
  • pylib2/foo/bar/b.py

This command works as expected:
bazel run --incompatible_default_to_explicit_init_py :test

While this command unexpectedly fails:
bazel build --incompatible_default_to_explicit_init_py :gen

... with this error:

Traceback (most recent call last):
  File "/home/bart/.cache/bazel/_bazel_bart/6a2c2a526fcecf9ab777dfd64f329e17/sandbox/linux-sandbox/6/execroot/__main__/bazel-out/host/bin/test.runfiles/__main__/test.py", line 2, in <module>
    import foo.bar.b
ModuleNotFoundError: No module named 'foo.bar.b'

Probably caused because Bazel created __init__.py files:

$ find bazel-out/ -name __init__.py
bazel-out/host/bin/test.runfiles/__main__/pylib2/foo/__init__.py
bazel-out/host/bin/test.runfiles/__main__/pylib2/foo/bar/__init__.py
bazel-out/host/bin/test.runfiles/__main__/pylib2/__init__.py
bazel-out/host/bin/test.runfiles/__main__/pylib1/foo/__init__.py
bazel-out/host/bin/test.runfiles/__main__/pylib1/foo/bar/__init__.py
bazel-out/host/bin/test.runfiles/__main__/pylib1/__init__.py

Replace this line with your answer.

What operating system are you running Bazel on?

This issue is reproducible on both Linux and Windows.

What's the output of bazel info release?

release 3.4.1 and release 3.6.0 on Linux
release 3.5.0 on Windows

Have you found anything relevant by searching the web?

I tried to search the github issue database and stackoverflow/google.

Any other information, logs, or outputs that you want to share?

Nope.

@LiyouZhou
Copy link

Is there a workaround for this?

fmeum added a commit to fmeum/bazel that referenced this issue Oct 11, 2022
Adding incompatible options is error-prone as it is easy to forget to
add them to their corresponding `FragmentOption`'s `getHost` method. If
this is not done, the flag will have no effect in the exec
configuration, which has already caused very surprising, buggy behavior
in numerous cases.

This commit adds a test to verify that all non-deprecated incompatible
flags:

1. are tagged with the `INCOMPATIBLE_CHANGE` metadata tag;
2. are preserved in the exec configuration.

Fixes bazelbuild#12238
Fixes bazelbuild#16388
fmeum added a commit to fmeum/bazel that referenced this issue Oct 11, 2022
Adding incompatible options is error-prone as adding them to their
corresponding `FragmentOption`'s `getHost` method is easily forgotten.
In that case, the flag will have no effect in the exec configuration,
which has already caused very surprising, buggy behavior in numerous
cases.

This commit adds a test to verify that all non-deprecated incompatible
flags:

1. are tagged with the `INCOMPATIBLE_CHANGE` metadata tag;
2. are preserved in the exec configuration.

Fixes bazelbuild#12238
Fixes bazelbuild#16388
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-Python Native rules for Python type: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants