From Bazel 2.0.0 onwards, Bazel looks for a binary named
`bazel-${version}-${os_arch}` if the project root contains a
`.bazelversion` file or the USE_BAZEL_VERSION environment
variable is set.
This change ensures we output a binary with the correct name
for the current version and OS/arch combination.
- Bazel strict action env set a default PATH to
`/bin/:/usr/bin:/usr/local/bin`. This was previously changed to disable
this behavior to improve hermeticity. However the previous change was
only removing `/bin:/usr/bin`, keeping `/usr/local/bin`, this commit
also remove this entry.
- Upgraded dependencies
- dependencies script upgraded to take into account new WORKSPACE
rules
- Tests now depends on the `distdir`
Runtime bazel now also depends on the `distdir` setting which appears
in the global configuration file. This increases the bazel closure
size by 85 MO for stuffs which can normally be downloaded at runtime
by bazel. However, any invocation of `buildBazelPackage` (such as in
`bazel-watcher`) may fail in nix sandbox if theses files are not
available at runtime.
If this overhead is too important, we may later evolve to a finer
grained solution, where buildBazelPackage declares the list of
necessary dependencies.
The bazel build patches paths like `/usr/bin/install_name_tool` to refer
to `${cctools}/bin/install_name_tool` instead. If the corresponding
runtime dependency is not denoted, then darwin users can encounter "file
not found" errors, e.g. when they fetch bazel from a binary cache and
don't have `cctools` in their own nix store.
The shebang in the python stub template was incorrectly patched to
```
<store-path>/bin/env python
```
instead of
```
<store-path>/bin/python
```
The reason was that `patchShebangs` was called with `--replace` which is
an unknown argument.
```
patching script interpreter paths in src/main/java/com/google/devtools/build/lib/bazel/rules/python/python_stub_template.txt --replace /usr/bin/env python /nix/store/w7gsq8v86hni4ynaqgwwlnlny115ylng-python3-3.7.4/bin/python
find: unknown predicate `--replace'
```
Using `substituteInPlace` instead resolves that issue.
The wrong shebang caused failures of `py_binary` targets due to `python`
not being in `PATH` in certain circumstances.
