Cannot build with --experimental_strict_action_env

[lunaris]

In trying to build with --experimental_strict_action_env (to see if it would help with some remote caching issues), I get errors relating to the fact that the ls_modules script cannot find python using env. The command that gets run is something like:

PATH=/nix/store/czx8vkrb9jdgjyz8qfksh10vrnqa723l-bash-4.4-p23/bin:/nix/store/wm8va53fh5158ipi0ic9gir64hrvqv1z-coreutils-8.29/bin:/nix/store/g5dlpwd44kd75i71nwzii8w4bp4inxwk-findutils-4.6.0/bin:/nix/store/9f89z51na7w931aja8lqlmhqny9h16cj-gnugrep-3.1/bin:/nix/store/ny5p32137wfyzdm485xfdck21w1gyl3g-gnused-4.5/bin:/nix/store/ckd1dy6llxr1s17f9x27p9jwzdanl5yx-which-2.21/bin \
  bazel-out/host/bin/external/io_tweag_rules_haskell/haskell/ls_modules bazel-out/k8-fastbuild/.../_iface bazel-out/host/bin/ghc-global-pkgdb bazel-out/k8-fastbuild/.../hidden-modules-api bazel-out/k8-fastbuild/.../reexported-modules-api bazel-out/k8-fastbuild/.../exposed-modules-api

It seems that python is not being put on the explicit PATH. I tried to rectify this by including a nixpkgs_package entry for python and using py_runtime to reference it in the haskell/BUILD file, as follows:

WORKSPACE

nixpkgs_package(
    name = "python-2715",
    repositories = { "nixpkgs": "@nixpkgs" },
    attribute_path = "python",
    build_file_content = """
package(default_visibility = ["//visibility:public"])
filegroup(
    name = "interpreter",
    srcs = ["bin/python"],
)
""",
)

haskell/BUILD

py_runtime(
    name = "python-2.7.15",
    files = [],
    interpreter = "@python-2715//:interpreter",
)

But this didn't change anything. But I'm probably making some bad assumptions/doing something wrong here.

[mboes]

Are you using Bazel from Nixpkgs? The official Bazel sets PATH=/usr/bin:/bin when you switch on --experimental_strict_action_env. On NixOS, that amounts to setting the PATH to an empty value pretty much, because there is nearly nothing in /bin or in /usr/bin. So the Bazel that ships in Nixpkgs has been patched to set the PATH to include coreutils, gnused and a few others instead, but nothing else. This set does not include Python, even though on any other system python would typically be found in /usr/bin and therefore Bazel rules work there, even with --experimental_strict_action_env.

So we have two choices:

• Patch Nixpkgs to include python in the strict env, arguing that Python is a "core utility" much like sed, find or mkdir are, which doesn't need to be part of the hermetic seal.
• Declare a toolchain for Python, then make ls_modules depend on this toolchain.

The latter looks more principled to me, but OTOH departs from what the other rule sets are doing, which seems to be to just assume some Python outside of the hermetic seal.

[Profpatsch]

• Patch Nixpkgs to include python in the strict env, arguing that Python is a "core utility"

This won’t fly, there is no one universally agreed on Python because of the v2 vs the v3 issue (like there is always one “current” Perl 5 interpreter). Most Python scripts don’t even specify which version they use (#!/usr/bin/python, ugh), even though they are incompatible (or at least untested) with one or the other.

[lunaris]

I tried the second option I think with py_runtime -- as far as I know there's not a py_toolchain? A third option therefore is (perhaps crazy) -- rewrite these scripts in another language we can have better control over (Bash or Haskell, perhaps)?

[mboes]

Bash would be a pain. The python code is quite pithy thanks to features that don't exist out-of-the-box in pure Bash. Haskell is an interesting option, but then there's a bootstrap problem. Not insurmountable - I think rules_go likewise bootstraps Go utilities used by the ruleset itself.

I'm curious about your caching issues. Maybe you want to write that up (as part of a separate ticket)?

[mboes]

BTW maybe your caching issues have the same root cause as #244? We haven't had a chance to investigate much yet, but IMO rules_haskell is doing some funny stuff under the hood that we shouldn't be doing.

[lunaris]

I'm not sure. I thought it might be Template Haskell (perhaps newName uses uniques that aren't always seeded the same if random/different compilation orders apply), but if it is then it seems quite specific (e.g. some packages [empirically] "consistently" hit cache despite using aeson's JSON-deriving TH). Will keep investigating to see if I can minimise. If it's related to #244 then it's a different symptom because I don't get any build errors per se, just no caching, and I've not once had to clean --expunge.

[mboes]

Blocked on bazelbuild/bazel#6817.

[brandjon]

Replied on that issue -- you may still be able to build with --experimental_strict_action_env if you add --python_top=//some/pyruntime:target to your bazelrc, where the py_runtime specifies the path to the interpreter.

[Profpatsch]

--strict_action_env was removed from bazel 0.22 onwards, because it broke too many downstream workflows.

[robinp]

Note to the future: as described in https://github.com/bazelbuild/bazel/blob/master/tools/python/toolchain.bzl, I added a nixpkgs-sourced python toolchain - see TreeTide/kythe@aa98d59.

(/cc tweag/rules_nixpkgs#39 since it was related)