--incompatible_default_to_explicit_init_py not respected when py_binary called from a rule with cfg="exec"

[mvukov]

Description of the bug:

In a .bazelrc I have defined build: --incompatible_default_to_explicit_init_py, needed for proper handling of automatically generated Python code for some Protobuf files. This auto-generated code is used in a py_binary. The binary works normally and the build option is respected. However, when I use the binary from a rule as e.g.

def _arule_impl(ctx):
    ctx.actions.run(
        ...
        executable = ctx.executable._tool,
    )

arule = rule(
    implementation = _arule_impl,
    attrs = {
        ...
        "_tool": attr.label(
            default = Label("//path/to:tool"),
            executable = True,
            cfg = "exec",
        ),
    },
)

then I get an import error related to the fact that the build option --incompatible_default_to_explicit_init_py isn't respected. A simple fix is to add legacy_create_init = False, to the py_binary definition.

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

No response

Which operating system are you running Bazel on?

Ubuntu 20.04

What is the output of bazel info release?

release 5.2.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

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

No response

[ShreeM01]

Hello @mvukov , It will be helpful if you could provide the minimal steps to reproduce the above request like sample repo? Thanks!

[martis42]

@kshyanashree
I can confirm this bug. It is annoying me for some time as well.
Most likely this issue is related, although it is about genrules: #12238

I created a small example project showcasing the bug for ctx.actions.run. See https://github.com/martis42/example_ignored_incompatible_default_to_explicit_init_py

Hopefully this helps reproducing and analyzing the problem. If you have any questions, feel free to reach out.

[mvukov]

@martis42 Thanks for providing a sample repo to easily reproduce the bug.