python_stub_template: AttributeError: 'module' object has no attribute 'OrderedDict' on CentOS 6
#11265
Labels
Comments
ghost
mentioned this issue
bazel-io
pushed a commit
that referenced
this issue
May 1, 2020
Commit d5012a7 introduced a Python 2.7 dependency into python_stub_template.txt. Unfortunately this stub is non-hermetic, so even if the user has configured Python 2.7 and 3 `py_runtime`s, their builds may fail if the system-provided Python is ancient (ex: CentOS 6.6 provides Python 2.6.6). Accommodate ancient Python by reworking the path deduplication in terms of a `set` and a generator instead of `collections.OrderedDict`. Workaround for #11265. Testing Done: - `bazelisk test //src/test/shell/integration:python_stub_test` - In a CentOS 6.6 env: ```console $ /usr/bin/env python -V Python 2.6.6 $ cat >test.py <<EOF import sys print(sys.executable) EOF $ cat >BUILD <<EOF py_binary(name = "test", srcs = ["test.py"]) EOF $ bazel run :test /path/to/my/hermetic/python3 ``` Closes #11269. PiperOrigin-RevId: 309450777
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the problem / feature request:
Recently upgraded to Bazel 3.1.0. Discovered that CentOS 6 users (don't ask) are now broken due to d5012a7.
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
#!/usr/bin/env pythoninvokes Python 2.6.6.py_binary, such as rules_pkg'sbuild_tar.What operating system are you running Bazel on?
CentOS 6.6
What's the output of
bazel info release?release 3.1.0-vmwareIf
bazel info releasereturns "development version" or "(@non-git)", tell us how you built Bazel.n/a
What's the output of
git remote get-url origin ; git rev-parse master ; git rev-parse HEAD?n/a
Have you found anything relevant by searching the web?
Any other information, logs, or outputs that you want to share?
Non-hermeticity is the key problem for me. We have Python toolchains to decouple our builds from tools provided by the user's OS, but the stub's shebang bypasses these.
Workarounds I'm considering:
%python_binary%instead of#!/usr/bin/env python.The text was updated successfully, but these errors were encountered: