Why does the name of a build target make or break the success of `bazel run`ing it?

[Josh Powell]

In my WORKSPACE file, I have the following

```new_git_repository(

    name = "com_github_google_yapf",

    build_file = "external/BUILD.yapf",

    commit = "46fe382ad2a2ed6281200149fc7c05c035678545",

    remote = "https://github.com/google/yapf",

)```

Here are the contents of BUILD.yapf:

```package(

    default_visibility = ["//visibility:public"],

)

load("@subpar//:subpar.bzl", "par_binary")

par_binary(

    name = "yapf_py",

    srcs = glob(["yapf/**/*.py"]),

    main = "yapf/__main__.py",

)```

If I run `bazel run @com_github_google_yapf//:yapf_py -- --help` I see the output from yapf's help "menu" plus some logging messages from Bazel.  If I renamed the par_binary target from "yapf_py" to "yapf" it no longer works.  There must be some kind of naming conflict between part of the path and the name of the target?  Or am I doing something wrong?  Below is the error message I see.  Any thoughts?

```Loading: 0 packages loaded

Loading: 0 packages loaded

INFO: Analysed target @com_github_google_yapf//:yapf (1 packages loaded).

INFO: Found 1 target...

blaze: Entering directory `/home/machine/.cache/bazel/_bazel_machine/315778c3ef57c07dcdd88fd922b4d319/execroot/sandbox/'

[0 / 2] BazelWorkspaceStatusAction stable-status.txt

blaze: Leaving directory `/home/machine/.cache/bazel/_bazel_machine/315778c3ef57c07dcdd88fd922b4d319/execroot/sandbox/'

Target @com_github_google_yapf//:yapf up-to-date:

  bazel-bin/external/com_github_google_yapf/yapf

INFO: Elapsed time: 1.621s, Critical Path: 0.00s

INFO: Build completed successfully, 1 total action

INFO: Running command line: bazel-bin/external/com_github_google_yapf/yapf --help

Traceback (most recent call last):

  File "/home/machine/.cache/bazel/machine/315778c3ef57c07dcdd88fd922b4d319/execroot/sandbox/bazel-out/local-opt/bin/

external/com_github_google_yapf/yapf", line 178, in <module>                                                         

    Main()

  File "/home/machine/.cache/bazel/_bazel_machine/315778c3ef57c07dcdd88fd922b4d319/execroot/sandbox/bazel-out/local-opt/bin/

external/com_github_google_yapf/yapf", line 145, in Main                                                             

    'Cannot exec() %r: file not found.' % main_filename

AssertionError: Cannot exec() '/home/machine/.cache/bazel/_bazel_machine/315778c3ef57c07dcdd88fd922b4d319/execroot/sandbox/b

azel-out/local-opt/bin/external/com_github_google_yapf/yapf.runfiles/sandbox/../com_github_google_yapf/yapf/__main__.p

y': file not found.                                                                                                  

ERROR: Non-zero return code '1' from command: Process exited with status 1

//home/machine/dev/sandbox```

[Brian Silverman]

Naming the binary "yapf" is asking for all the source files to be symlinked into a folder in the runfiles tree with the same name as the binary, which doesn't work. With the ancient Bazel version I had laying around (76139f2 from February 2016), that spews out warnings along these lines:

WARNING: /home/brian/.cache/bazel/_bazel_brian/7206377c5b9ae3abd82d104744270da7/external/com_github_google_yapf/BUILD:7:1: runfiles symlink external/com_github_google_yapf/yapf/yapflib/comment_splicer.py -> /home/brian/.cache/bazel/_bazel_brian/7206377c5b9ae3abd82d104744270da7/external/com_github_google_yapf/yapf/yapflib/comment_splicer.py obscured by external/com_github_google_yapf/yapf -> /home/brian/.cache/bazel/_bazel_brian/7206377c5b9ae3abd82d104744270da7/ajdklasdf/bazel-out/local_linux-fastbuild/bin/external/com_github_google_yapf/yapf.

Probably worth filing a bug for py_binary to do something more helpful with this situation in current versions (at least warn, if not just fail outright).

FWIW, I would name the rule "com_github_google_yapf" so you can just refer to it as "@com_github_google_yapf".

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/b44e122c-ffc8-414e-aee3-d256b9c592b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Josh Powell]

Thanks, Brian.  The pattern I'd adopted a while ago, probably when the warning message you copy would be provided, was to append the "_py" to the name.  But I'd forgotten why I was doing this.

Thanks for the additional tip about the name.  I'd seen that rules such as //path/to/package:package could be shortened to //path/to/package, but I hadn't realized the same sort of elision could be make with repository rule names.

To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.