-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Update platform support and require symengine #10902
Conversation
One or more of the the following people are requested to review this:
|
This commit updates our platform support matrix to reflect upcoming changes. The first is that in Rust 1.74 the Rust programming language is raising their minimum support macOS version to 10.12, so Qiskit is raising it's supported version of macOS to match this. The second change is making symengine a hard requirement. We previously had symengine as a requirement only on platforms that had precompiled packages available. But, the percentage of our user base that runs qiskit on those platforms is very small, and maintaining dual support for symengine and sympy adds a lot of complexity around managing the dependencies. This commit promotes symengine to a hard requirement for all users regardless of platform. As a result Linux i686 and 32 bit Windows for Python < 3.10 has been downgraded to tier 3 support as you'll need a C++ to install Qiskit on that platform now (regardless of Python version).
93eca8d
to
9a1d01b
Compare
This should be ready to go now, I fixed the bug with symengine in: 4bdcc20. I'm going to open a standalone PR for that though so we can backport it to 0.45.1 (I'll remove the release note once I do). |
This commit fixes an issue with the use_symengine flag on the qpy.dump() function. Previously in certain conditions a symengine expression that was listed in the qpy header as being encoded via symengine was incorrectly being serialized using sympy. This would cause a failure on deserialialization as the qpy payload was invalid and symengine could not parse a symengine representation. This was originally caught during the development of Qiskit#10902 as that switches the default of use_symengine to ``True`` as it makes symengine a hard requirement. This commit splits it out so the isolated fix can be backported to 0.45.1.
Pull Request Test Coverage Report for Build 6944386273Warning: This coverage report may be inaccurate.We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
💛 - Coveralls |
With the release 1.74 on 11-16-2023 the minimum supported macOS version by the Rust compiler is 10.12. For the 0.45.x release series we still support macOS 10.9 (this will change in 1.0 see Qiskit#10902). To faciliate still publishing wheels that will support macOS 10.9 for any future bugfix releases on 0.45.x release series (and 0.46.x too) this commit pins the rust toolchain version we use to 1.73 which is the last release that support 10.9.
Rust 1.74 released yesterday so the importance on this PR is increased a bit since whenever we tag a release we'll be pulling that in and won't be able to build binaries that are compatible with macOS 10.9. I do think we should wait for #11261 first though and then rebase this on top of that. |
) * Fix issue with ScheduleBlock qpy serialization and use_symengine This commit fixes an issue with the use_symengine flag on the qpy.dump() function. Previously in certain conditions a symengine expression that was listed in the qpy header as being encoded via symengine was incorrectly being serialized using sympy. This would cause a failure on deserialialization as the qpy payload was invalid and symengine could not parse a symengine representation. This was originally caught during the development of #10902 as that switches the default of use_symengine to ``True`` as it makes symengine a hard requirement. This commit splits it out so the isolated fix can be backported to 0.45.1. * Skip symengine test if symengine isn't installed * Fix skip syntax * Update releasenotes/notes/fix-schedule-qpy-use-symengine-05ae1dfab73e3ff8.yaml Co-authored-by: Jake Lishman <[email protected]> --------- Co-authored-by: Jake Lishman <[email protected]>
) * Fix issue with ScheduleBlock qpy serialization and use_symengine This commit fixes an issue with the use_symengine flag on the qpy.dump() function. Previously in certain conditions a symengine expression that was listed in the qpy header as being encoded via symengine was incorrectly being serialized using sympy. This would cause a failure on deserialialization as the qpy payload was invalid and symengine could not parse a symengine representation. This was originally caught during the development of #10902 as that switches the default of use_symengine to ``True`` as it makes symengine a hard requirement. This commit splits it out so the isolated fix can be backported to 0.45.1. * Skip symengine test if symengine isn't installed * Fix skip syntax * Update releasenotes/notes/fix-schedule-qpy-use-symengine-05ae1dfab73e3ff8.yaml Co-authored-by: Jake Lishman <[email protected]> --------- Co-authored-by: Jake Lishman <[email protected]> (cherry picked from commit 1dd4f54)
) (#11275) * Fix issue with ScheduleBlock qpy serialization and use_symengine This commit fixes an issue with the use_symengine flag on the qpy.dump() function. Previously in certain conditions a symengine expression that was listed in the qpy header as being encoded via symengine was incorrectly being serialized using sympy. This would cause a failure on deserialialization as the qpy payload was invalid and symengine could not parse a symengine representation. This was originally caught during the development of #10902 as that switches the default of use_symengine to ``True`` as it makes symengine a hard requirement. This commit splits it out so the isolated fix can be backported to 0.45.1. * Skip symengine test if symengine isn't installed * Fix skip syntax * Update releasenotes/notes/fix-schedule-qpy-use-symengine-05ae1dfab73e3ff8.yaml Co-authored-by: Jake Lishman <[email protected]> --------- Co-authored-by: Jake Lishman <[email protected]> (cherry picked from commit 1dd4f54) Co-authored-by: Matthew Treinish <[email protected]>
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.
Sorry for the chain of inline comments on the reno, I should have probably read it all at once and made a single suggestion. But these are all minor, overall LGTM.
# multiplication in version 0.10 wich breaks parameter assignment test | ||
# (can be removed once issue is fix) | ||
symengine>=0.9, <0.10; platform_machine == 'x86_64' or platform_machine == 'aarch64' or platform_machine == 'ppc64le' or platform_machine == 'amd64' or platform_machine == 'arm64' | ||
symengine>=0.9, <0.10 |
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.
should we keep the comment explaining why we are pinning symengine to <0.10?
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.
Yeah, normally I'd agree and add it back. But, #11262 uncaps the symengine version. So I don't think it matters too much anymore.
Co-authored-by: Elena Peña Tapia <[email protected]>
* Pin rust compiler version to 1.73 for wheel builds With the release 1.74 on 11-16-2023 the minimum supported macOS version by the Rust compiler is 10.12. For the 0.45.x release series we still support macOS 10.9 (this will change in 1.0 see #10902). To faciliate still publishing wheels that will support macOS 10.9 for any future bugfix releases on 0.45.x release series (and 0.46.x too) this commit pins the rust toolchain version we use to 1.73 which is the last release that support 10.9. * DNM: test wheel builds * Add win32 target * Only pin macOS version * Fix syntax error * Revert "DNM: test wheel builds" This reverts commit 9cbd70f. * Use stable on linux
* Update platform support and require symengine This commit updates our platform support matrix to reflect upcoming changes. The first is that in Rust 1.74 the Rust programming language is raising their minimum support macOS version to 10.12, so Qiskit is raising it's supported version of macOS to match this. The second change is making symengine a hard requirement. We previously had symengine as a requirement only on platforms that had precompiled packages available. But, the percentage of our user base that runs qiskit on those platforms is very small, and maintaining dual support for symengine and sympy adds a lot of complexity around managing the dependencies. This commit promotes symengine to a hard requirement for all users regardless of platform. As a result Linux i686 and 32 bit Windows for Python < 3.10 has been downgraded to tier 3 support as you'll need a C++ to install Qiskit on that platform now (regardless of Python version). * Fix use_symengine ScheduleBlock * Remove duplicated release note * Apply suggestions from code review Co-authored-by: Elena Peña Tapia <[email protected]> --------- Co-authored-by: Elena Peña Tapia <[email protected]>
Summary
This commit updates our platform support matrix to reflect upcoming changes. The first is that in Rust 1.74 the Rust programming language is raising their minimum support macOS version to 10.12, so Qiskit is raising it's supported version of macOS to match this. The second change is making symengine a hard requirement. We previously had symengine as a requirement only on platforms that had precompiled packages available. But, the percentage of our user base that runs qiskit on those platforms is very small, and maintaining dual support for symengine and sympy adds a lot of complexity around managing the dependencies. This commit promotes symengine to a hard requirement for all users regardless of platform. As a result Linux i686 and 32 bit Windows for Python < 3.10 has been downgraded to tier 3 support as you'll need a C++ to install Qiskit on that platform now (regardless of Python version).
Details and comments
This PR is on hold until after the 0.45.0 release. These platform changes don't apply to the 0.45.0 release, I just wanted to push them up earlier so we can debug any potential issues prior well in advance of making the change.