Native python rules have a couple of problems, which can be fixed by using
proper bazel toolchains for the python rules:
Switching between py2 and py3 runtimes (--python_top) trashes the
test/action cache. This is because building "foo" generates bazel-bin/foo
and bazel-bin/foo.runfiles for both py2 and py3 builds.
=> Proper python toolchain allows us to produce bazel-bin/foo/{py2,py3}/foo
and bazel-bin/foo/{py2,py3}/foo.runfiles and hence avoid cache trashing.
The launcher script begins with "#/usr/bin/env python", which means it
relies on system-installed default python interpreter.
=> Proper python toolchain allows us to use a bash script as the launcher.
Site packages are leaked into the python app, because the interpreter
is not started with "-s -S" flags.
=> Proper python toolchain gives us full control of the launcher scipt,
allowing us to pass the "-s -S" flags (if we want).
Native python rules have a couple of problems, which can be fixed by using proper bazel toolchains for the python rules:
Switching between py2 and py3 runtimes (--python_top) trashes the test/action cache. This is because building "foo" generates bazel-bin/foo and bazel-bin/foo.runfiles for both py2 and py3 builds.
=> Proper python toolchain allows us to produce bazel-bin/foo/{py2,py3}/foo and bazel-bin/foo/{py2,py3}/foo.runfiles and hence avoid cache trashing.
The launcher script begins with "#/usr/bin/env python", which means it relies on system-installed default python interpreter.
=> Proper python toolchain allows us to use a bash script as the launcher.
Site packages are leaked into the python app, because the interpreter is not started with "-s -S" flags.
=> Proper python toolchain gives us full control of the launcher scipt, allowing us to pass the "-s -S" flags (if we want).