11

I have set up bazel to build a number of CLI tools that perform various database maintenance tasks. Each one is a py_binary or cc_binary target that is called from the command line with the path to some data file: it processes that file and stores the results in a database.

Now, I need to create a dependent package that contains data files and shell scripts that call these CLI tools to perform application-specific database operations.

However, there doesn't seem to be a way to depend on the existing py_binary or cc_binary targets from a new package that only contains sh_binary targets and data files. Trying to do so results in an error like:

ERROR: /workspace/shbin/BUILD.bazel:5:12: in deps attribute of sh_binary rule //shbin:run: py_binary rule '//pybin:counter' is misplaced here (expected sh_library)

Is there a way to call/depend on an existing bazel binary target from a shell script using sh_binary?

I have implemented a full example here: https://github.com/psigen/bazel-mixed-binaries


Notes:

I cannot use py_library and cc_library instead of py_binary and cc_binary. This is because (a) I need to call mixes of the two languages to process my data files and (b) these tools are from an upstream repository where they are already designed as CLI tools.

I also cannot put all the data files into the CLI tool packages -- there are multiple application-specific packages and they cannot be mixed.

psigen
  • 163
  • 1
  • 2
  • 9

3 Answers3

19

You can either create a genrule to run these tools as part of the build, or create a sh_binary that depends on the tools via the data attribute and runs them them.

The genrule approach

This is the easier way and lets you run the tools as part of the build.

genrule(
    name = "foo",
    tools = [
        "//tool_a:py",
        "//tool_b:cc",
    ],
    srcs = [
        "//source:file1",
        ":file2",
    ],
    outs = [
        "output_file1",
        "output_file2",
    ],
    cmd = "$(location //tool_a:py) --input=$(location //source:file1) --output=$(location output_file1) && $(location //tool_b:cc) < $(location :file2) > $(location output_file2)",
)

The sh_binary approach

This is more complicated, but lets you run the sh_binary either as part of the build (if it is in a genrule.tools, similar to the previous approach) or after the build (from under bazel-bin).

In the sh_binary you have to data-depend on the tools:

sh_binary(
    name = "foo",
    srcs = ["my_shbin.sh"],
    data = [
        "//tool_a:py",
        "//tool_b:cc",
    ],
)

Then, in the sh_binary you have to use the so-called "Bash runfiles library" built into Bazel to look up the runtime-path of the binaries. This library's documentation is in its source file.

The idea is:

  1. the sh_binary has to depend on a specific target
  2. you have to copy-paste some boilerplate code to the top of the sh_binary (reason is described here)
  3. then you can use the rlocation function to look up the runtime-path of the binaries

For example your my_shbin.sh may look like this:

#!/bin/bash
# --- begin runfiles.bash initialization ---
...
# --- end runfiles.bash initialization ---

path=$(rlocation "__main__/tool_a/py")
if [[ ! -f "${path:-}" ]]; then
  echo >&2 "ERROR: could not look up the Python tool path"
  exit 1
fi
$path --input=$1 --output=$2

The __main__ in the rlocation path argument is the name of the workspace. Since your WORKSPACE file does not have a "workspace" rule in, which would define the workspace's name, Bazel will use the default workspace name, which is __main__.

László
  • 3,973
  • 1
  • 13
  • 26
  • Thanks @Laszlo, the second approach is working great! – psigen Dec 13 '18 at 22:50
  • Thanks for your edit suggestions [psigen](https://stackoverflow.com/users/2044807/psigen)! Apparently it was rejected. I edited the original post with the bugfix for the shell script. – László Dec 17 '18 at 09:33
  • 2
    If you are trying to use the second approach, make sure the boilerplate you copy paste into your shell script is from master, it has changed a bit since this post was first written. – Brian Barnes Apr 24 '20 at 18:57
  • I tried to use the same way to start a java binary target in Bazel, but unfortunately i got an error `Cannot locate runfiles directory. (Set $JAVA_RUNFILES to inhibit searching.)`. Where may i find those java runfiles? – user14042594 Aug 26 '22 at 01:33
6

A clean way to do this is to use args and $(location):

Contents of BUILD:

py_binary(
    name = "counter",
    srcs = ["counter.py"],
    main = "counter.py",
)

sh_binary(
    name = "run",
    srcs = ["run.sh"],
    data = [":counter"],
    args = ["$(location :counter)"],
)

Contents of counter.py (your tool):

print("This is the counter tool.")

Contents of run.sh (your bash script):

#!/bin/bash
set -eEuo pipefail

counter="$1"
shift

echo "This is the bash script, about to call the counter tool."
"$counter"

And here's a demo showing the bash script calling the Python tool:

$ bazel run //example:run 2>/dev/null
This is the bash script, about to call the counter tool.
This is the counter tool.

It's also worth mentioning this note (from the docs):

The arguments are not passed when you run the target outside of bazel (for example, by manually executing the binary in bazel-bin/).

ron rothman
  • 17,348
  • 7
  • 41
  • 43
  • 1
    MVP right here! This is the only solution that worked for me thank you – Kyle Bridenstine Oct 19 '21 at 17:11
  • This works really well. However, if the `sh` file has a package that has been installed via pip e.g `celery` and you perform an action e.g `celery -A xxx worker -l INFO &> /app/logs/celery.log &` , you will still get an error about `celery`. Is there away to make `sh_binary` know about the installed packages? See this question https://stackoverflow.com/questions/71602479/does-bazel-sh-binary-allow-calling-of-scripts-that-depends-on-some-pip-packages – E_K Mar 24 '22 at 13:12
  • Your sh binary can do anything it likes, including setting `PYTHONPATH`. But that would make your build non-hermetic, so you probably want to avoid it. – ron rothman Mar 24 '22 at 13:17
5

An easier approach for me is to add the cc_binary as a dependency in the data section. In prefix/BUILD

cc_binary(name = "foo", ...)
sh_test(name = "foo_test", srcs = ["foo_test.sh"], data = [":foo"])

Inside foo_test.sh, the working directory is different, so you need to find the right prefix for the binary

#! /usr/bin/env bash

executable=prefix/foo

$executable ...
Fred Schoen
  • 1,372
  • 13
  • 18
  • That's also how you can depend on shared libraries created by some other target that you want to use in a `py_binary` or `py_library`. – ahans Feb 07 '19 at 10:53
  • This should be the accepted answer. There is no need to use rlocation for this. – Brian Barnes Apr 24 '20 at 21:19