1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
#!/bin/sh
# Don't set -e because we don't have robust trapping and printing of errors.
set -u
# We use /bin/sh rather than /bin/bash for portability. See discussion here:
# https://groups.google.com/forum/?nomobile=true#!topic/bazel-dev/4Ql_7eDcLC0
# We do lose the ability to set -o pipefail.
STRICT="%STRICT%"
if [ "$STRICT" = "1" ]; then
FAILURE_HEADER="\
Error occurred while attempting to use the default Python toolchain \
(@rules_python//python:autodetecting_toolchain)."
else
FAILURE_HEADER="\
Error occurred while attempting to use the non-strict autodetecting Python \
toolchain (@rules_python//python:autodetecting_toolchain_nonstrict)."
fi
die() {
echo "$FAILURE_HEADER" 1>&2
echo "$1" 1>&2
exit 1
}
# We use `which` to locate the Python interpreter command on PATH. `command -v`
# is another option, but it doesn't check whether the file it finds has the
# executable bit.
#
# A tricky situation happens when this wrapper is invoked as part of running a
# tool, e.g. passing a py_binary target to `ctx.actions.run()`. Bazel will unset
# the PATH variable. Then the shell will see there's no PATH and initialize its
# own, sometimes without exporting it. This causes `which` to fail and this
# script to think there's no Python interpreter installed. To avoid this we
# explicitly pass PATH to each `which` invocation. We can't just export PATH
# because that would modify the environment seen by the final user Python
# program.
#
# See also:
#
# https://github.com/bazelbuild/continuous-integration/issues/578
# https://github.com/bazelbuild/bazel/issues/8414
# https://github.com/bazelbuild/bazel/issues/8415
# Try the "python%VERSION%" command name first, then fall back on "python".
PYTHON_BIN="$(PATH="$PATH" which python%VERSION% 2> /dev/null)"
USED_FALLBACK="0"
if [ -z "${PYTHON_BIN:-}" ]; then
PYTHON_BIN="$(PATH="$PATH" which python 2>/dev/null)"
USED_FALLBACK="1"
fi
if [ -z "${PYTHON_BIN:-}" ]; then
die "Neither 'python%VERSION%' nor 'python' were found on the target \
platform's PATH, which is:
$PATH
Please ensure an interpreter is available on this platform (and marked \
executable), or else register an appropriate Python toolchain as per the \
documentation for py_runtime_pair \
(https://github.com/bazelbuild/rules_python/blob/master/docs/python.md#py_runtime_pair)."
fi
if [ "$STRICT" = "1" ]; then
# Verify that we grabbed an interpreter with the right version.
VERSION_STR="$("$PYTHON_BIN" -V 2>&1)" \
|| die "Could not get interpreter version via '$PYTHON_BIN -V'"
if ! echo "$VERSION_STR" | grep -q " %VERSION%\." ; then
die "According to '$PYTHON_BIN -V', version is '$VERSION_STR', but we \
need version %VERSION%. PATH is:
$PATH
Please ensure an interpreter with version %VERSION% is available on this \
platform as 'python%VERSION%' or 'python', or else register an appropriate \
Python toolchain as per the documentation for py_runtime_pair \
(https://github.com/bazelbuild/rules_python/blob/master/docs/python.md#py_runtime_pair).
Note that prior to Bazel 0.27, there was no check to ensure that the \
interpreter's version matched the version declared by the target (#4815). If \
your build worked prior to Bazel 0.27, and you're sure your targets do not \
require Python %VERSION%, you can opt out of this version check by using the \
non-strict autodetecting toolchain instead of the standard autodetecting \
toolchain. This can be done by passing the flag \
\`--extra_toolchains=@rules_python//python:autodetecting_toolchain_nonstrict\` \
on the command line or adding it to your bazelrc."
fi
fi
exec "$PYTHON_BIN" "$@"
|
