-
Notifications
You must be signed in to change notification settings - Fork 519
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
feat: Add s390x release #1352
feat: Add s390x release #1352
Conversation
@rickeylev the error seen in the CI builds can be fixed with below patch:
However I am not sure about the impact of this change. Also please let me know whether updating "MINOR_MAPPING" versions as done in this PR is not ideal. |
@namrata-ibm, #1340 should fix what you mention in your message, then we would only have |
I think the minor mapping changes are good and they should stay in this PR,
if any other code is broken, it should be fixed.
…On Tue, 1 Aug 2023, 18:12 Namrata Bhave, ***@***.***> wrote:
Thank you @aignas <https://github.com/aignas> for pointing out.
Will check #1340 <#1340>
for further updates. If it is ongoing work and might take longer, then I
can revert the MINOR_MAPPING changes from this PR.
However it would be good to have, to avoid explicit python version
setting(eg in TensorFlow) during build on s390x.
—
Reply to this email directly, view it on GitHub
<#1352 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB22KVIXRBISSLHB2I3H43XTDB7TANCNFSM6AAAAAA27G6IVE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@namrata-ibm please take a look at CI/CD failures: https://buildkite.com/bazel/rules-python-python/builds/5380#0189af9c-468d-4b55-ac85-9954d0197118 |
@chrislovecnm Thank you for checking, all the CI failures are same and addressed in above comments. It would be great to hear comments about the queries listed up. |
@namrata-ibm, could you see if you can fix the WORKSPACE with the expected command please? Replacing |
@aignas I added the WORKSPACE change and all earlier failures have passed in latest run. However I see |
@namrata-ibm, this looks like a CI flake. |
Before this PR the `bzlmod` and legacy setups would only expose the multi-version python toolchain aliases as the string that is passed to the `python_register_multi_toolchains` function. This meant that if the user decided to pass the full version (e.g. `3.11.1`) then they had to import the version aware `py_*` defs via `@foo//3.11.1:defs.bzl`. This PR changes it such that the user can still do the old way of importing but we print a deprecation warning and ask the user to use `3.11:defs.bzl` instead which better reflects how the multi-version toolchain should be used. This also means that the PRs bumping the minor versions like in bazelbuild#1352 won't need updating Python code elsewhere. Whilst at it, we introduce a validation that disallows multiple Python toolchains of the same `X.Y` version. This is handled in the `bzlmod` by printing warnings that the toolchains are ignored, whilst the non-bzlmod users will get validation errors, which is a potentially breaking change. Fixes bazelbuild#1339
Before this PR the `bzlmod` and legacy setups would only expose the multi-version python toolchain aliases as the string that is passed to the `python_register_multi_toolchains` function. This meant that if the user decided to pass the full version (e.g. `3.11.1`) then they had to import the version aware `py_*` defs via `@foo//3.11.1:defs.bzl`. This PR changes it such that the user can still do the old way of importing but we print a deprecation warning and ask the user to use `3.11:defs.bzl` instead which better reflects how the multi-version toolchain should be used. This also means that the PRs bumping the minor versions like in bazelbuild#1352 won't need updating Python code elsewhere. Whilst at it, we introduce a validation that disallows multiple Python toolchains of the same `X.Y` version. This is handled in the `bzlmod` by printing warnings that the toolchains are ignored, whilst the non-bzlmod users will get validation errors, which is a potentially breaking change. Fixes bazelbuild#1339
@aignas did we hit a bug in buildifier? |
@aignas @chrislovecnm @rickeylev could you please provide your inputs on how to proceed further? |
@namrata-ibm the error from CI :bazel: buildifier: found 1 format issue in your WORKSPACE, BUILD and *.bzl files--
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR. Please run buildifier
to get CI passing. I think we should have two PRs here.
- include support for the new Python versions and support for
s390x
. - after that PR bump the mappings to increase the default version numbers
python/versions.bzl
Outdated
"x86_64-unknown-linux-gnu": "e26247302bc8e9083a43ce9e8dd94905b40d464745b1603041f7bc9a93c65d05", | ||
}, | ||
"strip_prefix": "python", | ||
}, | ||
} | ||
|
||
# buildifier: disable=unsorted-dict-items | ||
MINOR_MAPPING = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rather have the updates to MINOR_MAPPING
in a different PR. If we have problems with updating this mapping, we can back that out, and keep the s390x
support.
@@ -153,6 +153,19 @@ TOOL_VERSIONS = { | |||
}, | |||
"strip_prefix": "python", | |||
}, | |||
"3.9.17": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rickeylev @aignas any other Python versions that we should have s390x
support for?
4c9417a
to
53213fa
Compare
Needed to build TensorFlow on s390x.
eeea7a1
to
1785d40
Compare
@chrislovecnm Thank you, I have updated this PR to keep only s390x and python version updates. Could you please check and help merge this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This PR bumps mappings to latest version. Adding changes in a separate PR as discussed [here](#1352 (review)). cc @chrislovecnm
Before this PR the `bzlmod` and legacy setups would only expose the multi-version python toolchain aliases as the string that is passed to the `python_register_multi_toolchains` function. This meant that if the user decided to pass the full version (e.g. `3.11.1`) then they had to import the version aware `py_*` defs via `@foo//3.11.1:defs.bzl`. This PR changes it such that the user can still do the old way of importing but we print a deprecation warning and ask the user to use `3.11:defs.bzl` instead which better reflects how the multi-version toolchain should be used. This also means that the PRs bumping the minor versions like in bazelbuild#1352 won't need updating Python code elsewhere. Whilst at it, we introduce a validation that disallows multiple Python toolchains of the same `X.Y` version. This is handled in the `bzlmod` by printing warnings that the toolchains are ignored, whilst the non-bzlmod users will get validation errors, which is a potentially breaking change. Fixes bazelbuild#1339
Include s390x in release and update python-build-standalone to 3.9.17, 3.10.12, 3.11.4.
Latest python-build-standalone release has s390x support added.
These changes are needed to build TensorFlow on s390x, which is currently blocked due to missing support.