Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build breakage with upcoming Bazel change for Python toolchains #9

Closed
brandjon opened this issue May 13, 2019 · 5 comments
Closed

Build breakage with upcoming Bazel change for Python toolchains #9

brandjon opened this issue May 13, 2019 · 5 comments
Assignees

Comments

@brandjon
Copy link

This project fails to build when --incompatible_use_python_toolchains is enabled. It looks like you have a Python 2 target used as a tool in the host configuration, but the host configuration by default uses Python 3. We don't support multiple Python versions in the host configuration, but you can choose which version is used build-wide by setting --host_force_python=PY2. See the migration bug and bazelbuild/bazel#6443 for details.

cloud-robotics-github-robot pushed a commit that referenced this issue May 14, 2019
With the upcoming change in Bazel 0.27 in how the Python runtime is obtained
(test with --incompatible_use_python_toolchains), the host configuration
by default will use Python 3. This causes the build to fail because
pip_import/pip_install for some reason still download the
Python-2-compatible version of PyYAML.

See #9.

Change-Id: I7bb5408263278114160fe0308490c5803914e03c
GitOrigin-RevId: 5ac81e3
@davschm
Copy link
Contributor

davschm commented May 14, 2019

Thanks for making us aware of this. We have temporarily fixed it with --host_force_python=PY2 in
e028093.

The problem seems to be that pip_import and pip_install still download Python-2-compatible wheels of the dependencies even though the host configuration uses Python 3. Do you have any suggestion what to do about this?

@davschm davschm closed this as completed May 16, 2019
@brandjon
Copy link
Author

This will have to be fixed in rules_python. I can look into that after this toolchain flag flip is in. In the meantime --host_force_python is the way to go if you have PY2-only targets built in the host configuration.

I'm reopening this because this project is still failing in our downstream CI. Looking at one of the failures, I see here that the python_version attribute is not set (in the py_test created by ros_py_test). The default is PY3, so you may need to add python_version = "PY2" to the macro (or pass it in as a macro parameter if the required version differs between call sites).

@brandjon
Copy link
Author

Er, I'm not reopening this because I forgot I'm posting in a repo I don't have commit rights to. Leaving that to you. =)

@drigz
Copy link
Contributor

drigz commented Jun 3, 2019

Thanks for the pointer, will look into why the previous commit didn't fix it!

@drigz drigz reopened this Jun 3, 2019
@drigz drigz assigned drigz and unassigned davschm Jun 3, 2019
@brandjon
Copy link
Author

brandjon commented Jun 4, 2019

Confirmed fixed in most recent CI run. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants