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.

Sign up for GitHub

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

Jump to bottom

Support autodetecting toolchain on windows #7844

Closed
brandjon opened this issue Mar 26, 2019 · 7 comments
Closed

Support autodetecting toolchain on windows #7844

brandjon opened this issue Mar 26, 2019 · 7 comments
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-Rules-Python Native rules for Python type: feature request

Comments

@brandjon
Copy link
Member

We're currently supporting this on linux. Windows support requires rewriting the pywrapper shell script in .bat, and is also blocked on bazelbuild/continuous-integration#578.
@brandjon brandjon added type: feature request P2 We'll consider working on this in future. (Assignee optional) team-Rules-Python Native rules for Python labels Mar 26, 2019
bazel-io pushed a commit that referenced this issue Mar 26, 2019
@brandjon @copybara-github
Implement autodetecting Python toolchain
2299445 
This replaces the stub default Python toolchain with one that actually locates the target platform's Python interpreter at runtime. Try it out with

    bazel build //some_py_binary --experimental_use_python_toolchains

and note that, unlike before (#4815), the correct Python interpreter gets invoked by default regardless of whether you specify `--python_version=PY2` or `--python_version=PY3`.

This toolchain is only intended as a last resort, if the user doesn't define and register a better toolchain (that satisfies the target platform constraints).

Work toward #7375 and #4815. Follow-up work needed to add a test (#7843) and windows support (#7844).

RELNOTES: None
PiperOrigin-RevId: 240417315
@brandjon
Copy link
Member Author

Just realized that by adding an autodetecting toolchain that doesn't work for windows, I'm breaking the default behavior on windows for when --incompatible_use_python_toolchains is turned on. Easiest way to resolve is to add a hack to override the autodetecting toolchain with the legacy behavior on windows, until a proper default toolchain for it is implemented.

@brandjon brandjon mentioned this issue Mar 29, 2019
Closed
@brandjon
Copy link
Member Author

Also make sure to update site/docs/windows.md.

@brandjon brandjon mentioned this issue Mar 29, 2019
Closed
bazel-io pushed a commit that referenced this issue Mar 29, 2019
@brandjon @copybara-github
On Windows, have the autodetecting Python toolchain revert to reading…
54b1eb9 
… --python_path

This works around the fact that the autodetecting toolchain doesn't run under Windows (#7844). We'll have to add a Windows toolchain in the future, and then remove --python_path (and also address the EnsurePythonPathOption behavior in blaze_util_windows.cc).

RELNOTES: None
PiperOrigin-RevId: 241051815
@brandjon brandjon mentioned this issue Apr 1, 2019
Closed
@brandjon
Copy link
Member Author

An alternative to implementing this toolchain for windows would be to just have a repo rule create a toolchain for the host system. This might help eliminate that --python_path hackery in the bazel client under windows.

@brandjon brandjon mentioned this issue May 21, 2019
Closed
@brandjon
Copy link
Member Author

See here for more discussion relating to detecting the interpreter at workspace evaluation time versus execution time. Looks like workspace time is preferred.

bazel-io pushed a commit that referenced this issue May 29, 2019
@brandjon @copybara-github
Enable Python integration tests on Windows
2902623 
Now that we have both a Python 2 and 3 interpreter on our CI machines (bazelbuild/continuous-integration#578), we can turn on these version tests for Windows. Since there's no autodetecting toolchain for Windows yet (#7844) we define an explicit toolchain.

Fixes #8411.

RELNOTES: None
PiperOrigin-RevId: 250562174
irengrig pushed a commit to irengrig/bazel that referenced this issue Jun 18, 2019
@brandjon @irengrig
Enable Python integration tests on Windows
7daa1fd 
Now that we have both a Python 2 and 3 interpreter on our CI machines (bazelbuild/continuous-integration#578), we can turn on these version tests for Windows. Since there's no autodetecting toolchain for Windows yet (bazelbuild#7844) we define an explicit toolchain.

Fixes bazelbuild#8411.

RELNOTES: None
PiperOrigin-RevId: 250562174
irengrig pushed a commit to irengrig/bazel that referenced this issue Jul 15, 2019
@brandjon @irengrig
Enable Python integration tests on Windows
10840c4 
Now that we have both a Python 2 and 3 interpreter on our CI machines (bazelbuild/continuous-integration#578), we can turn on these version tests for Windows. Since there's no autodetecting toolchain for Windows yet (bazelbuild#7844) we define an explicit toolchain.

Fixes bazelbuild#8411.

RELNOTES: None
PiperOrigin-RevId: 250562174
@Globegitter Globegitter mentioned this issue Jul 16, 2019
Merged
@lberki lberki added P3 We're not considering working on this, but happy to review a PR. (No assignee) and removed P2 We'll consider working on this in future. (Assignee optional) labels Nov 18, 2020
@Warchant
Copy link
Contributor

python_path is counted in configuration hash calculation, which means that 2 windows machines won't share same "remote cache" if python is installed in different paths, even if everything else is same. Even if python is not used by the project.
#3717 (comment)

@github-actions
Copy link

github-actions bot commented Jun 8, 2023

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

@github-actions github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label Jun 8, 2023
@github-actions
Copy link

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-Rules-Python Native rules for Python type: feature request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@brandjon @Warchant @lberki