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

Pin z3-solver on macOS VMs #11408

Merged
merged 1 commit into from
Dec 13, 2023
Merged

Pin z3-solver on macOS VMs #11408

merged 1 commit into from
Dec 13, 2023

Conversation

jakelishman
Copy link
Member

Summary

We currently use macOS 11.7 images in our CI and CPython 3.8 for the all-optionals test run. z3-solver recently released 4.12.3.0, which upped the macOS platform version from 10.16 to 11.7. This in theory should be fine for our VM image, but the pre-built version of CPython 3.8 we have access to was built for an older macOS, so does not match a macos_11_7_x86_64 platform tag, and forces us to build Z3 from source, often timing out the job.

This should have no effect on user machines, which will be typically be using newer versions of Python, or will be able to install from source if required.

This CI-only constraint can be relaxed when the version of CPython we use on the macOS VMs supports the 11.7 macOS API version.

Details and comments

We currently use macOS 11.7 images in our CI and CPython 3.8 for the
all-optionals test run.  `z3-solver` recently released 4.12.3.0, which
upped the macOS platform version from 10.16 to 11.7.  This in theory
should be fine for our VM image, but the pre-built version of CPython
3.8 we have access to was built for an older macOS, so does not match a
`macos_11_7_x86_64` platform tag, and forces us to build Z3 from source,
often timing out the job.

This should have no effect on user machines, which will be typically be
using newer versions of Python, or will be able to install from source
if required.

This CI-only constraint can be relaxed when the version of CPython we
use on the macOS VMs supports the 11.7 macOS API version.
@jakelishman jakelishman added type: qa Issues and PRs that relate to testing and code quality stable backport potential The bug might be minimal and/or import enough to be port to stable Changelog: None Do not include in changelog labels Dec 13, 2023
@jakelishman jakelishman requested a review from a team as a code owner December 13, 2023 14:54
@qiskit-bot
Copy link
Collaborator

One or more of the the following people are requested to review this:

  • @Qiskit/terra-core

Copy link
Collaborator

@Eric-Arellano Eric-Arellano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing this and the clear comment in constraints.txt :)

@jakelishman
Copy link
Member Author

If we start having these problems a lot more1 we can potentially look at managing CPython through Homebrew or Conda on the image machines, but I'm somewhat unkeen to take that step unless we have to, since it'll add a non-trivial amount of install/build/configuration time to every macOS CI job.

Footnotes

  1. Qiskit supports all CPythons through to their EOL, which is unusually long, but driven by us being aware of backend deployments of us that update Python very infrequently.

@ElePT ElePT enabled auto-merge December 13, 2023 15:05
@coveralls
Copy link

Pull Request Test Coverage Report for Build 7196975002

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • 21 unchanged lines in 4 files lost coverage.
  • Overall coverage decreased (-0.01%) to 87.54%

Files with Coverage Reduction New Missed Lines %
crates/qasm2/src/expr.rs 1 93.76%
crates/qasm2/src/lex.rs 6 91.41%
crates/qasm2/src/parse.rs 6 97.6%
crates/accelerate/src/quantum_circuit/circuit_data.rs 8 90.71%
Totals Coverage Status
Change from base Build 7163309461: -0.01%
Covered Lines: 59763
Relevant Lines: 68269

💛 - Coveralls

@ElePT ElePT added this pull request to the merge queue Dec 13, 2023
Merged via the queue into Qiskit:main with commit c865c56 Dec 13, 2023
13 checks passed
mergify bot pushed a commit that referenced this pull request Dec 13, 2023
We currently use macOS 11.7 images in our CI and CPython 3.8 for the
all-optionals test run.  `z3-solver` recently released 4.12.3.0, which
upped the macOS platform version from 10.16 to 11.7.  This in theory
should be fine for our VM image, but the pre-built version of CPython
3.8 we have access to was built for an older macOS, so does not match a
`macos_11_7_x86_64` platform tag, and forces us to build Z3 from source,
often timing out the job.

This should have no effect on user machines, which will be typically be
using newer versions of Python, or will be able to install from source
if required.

This CI-only constraint can be relaxed when the version of CPython we
use on the macOS VMs supports the 11.7 macOS API version.

(cherry picked from commit c865c56)

# Conflicts:
#	constraints.txt
jakelishman added a commit that referenced this pull request Dec 13, 2023
We currently use macOS 11.7 images in our CI and CPython 3.8 for the
all-optionals test run.  `z3-solver` recently released 4.12.3.0, which
upped the macOS platform version from 10.16 to 11.7.  This in theory
should be fine for our VM image, but the pre-built version of CPython
3.8 we have access to was built for an older macOS, so does not match a
`macos_11_7_x86_64` platform tag, and forces us to build Z3 from source,
often timing out the job.

This should have no effect on user machines, which will be typically be
using newer versions of Python, or will be able to install from source
if required.

This CI-only constraint can be relaxed when the version of CPython we
use on the macOS VMs supports the 11.7 macOS API version.

(cherry picked from commit c865c56)
@jakelishman jakelishman deleted the pin-z3 branch December 13, 2023 18:37
github-merge-queue bot pushed a commit that referenced this pull request Dec 14, 2023
We currently use macOS 11.7 images in our CI and CPython 3.8 for the
all-optionals test run.  `z3-solver` recently released 4.12.3.0, which
upped the macOS platform version from 10.16 to 11.7.  This in theory
should be fine for our VM image, but the pre-built version of CPython
3.8 we have access to was built for an older macOS, so does not match a
`macos_11_7_x86_64` platform tag, and forces us to build Z3 from source,
often timing out the job.

This should have no effect on user machines, which will be typically be
using newer versions of Python, or will be able to install from source
if required.

This CI-only constraint can be relaxed when the version of CPython we
use on the macOS VMs supports the 11.7 macOS API version.

(cherry picked from commit c865c56)

Co-authored-by: Jake Lishman <[email protected]>
mergify bot added a commit that referenced this pull request Dec 14, 2023
We currently use macOS 11.7 images in our CI and CPython 3.8 for the
all-optionals test run.  `z3-solver` recently released 4.12.3.0, which
upped the macOS platform version from 10.16 to 11.7.  This in theory
should be fine for our VM image, but the pre-built version of CPython
3.8 we have access to was built for an older macOS, so does not match a
`macos_11_7_x86_64` platform tag, and forces us to build Z3 from source,
often timing out the job.

This should have no effect on user machines, which will be typically be
using newer versions of Python, or will be able to install from source
if required.

This CI-only constraint can be relaxed when the version of CPython we
use on the macOS VMs supports the 11.7 macOS API version.

(cherry picked from commit c865c56)

Co-authored-by: Jake Lishman <[email protected]>
(cherry picked from commit ef21b50)
github-merge-queue bot pushed a commit that referenced this pull request Dec 14, 2023
We currently use macOS 11.7 images in our CI and CPython 3.8 for the
all-optionals test run.  `z3-solver` recently released 4.12.3.0, which
upped the macOS platform version from 10.16 to 11.7.  This in theory
should be fine for our VM image, but the pre-built version of CPython
3.8 we have access to was built for an older macOS, so does not match a
`macos_11_7_x86_64` platform tag, and forces us to build Z3 from source,
often timing out the job.

This should have no effect on user machines, which will be typically be
using newer versions of Python, or will be able to install from source
if required.

This CI-only constraint can be relaxed when the version of CPython we
use on the macOS VMs supports the 11.7 macOS API version.

(cherry picked from commit c865c56)

Co-authored-by: Jake Lishman <[email protected]>
(cherry picked from commit ef21b50)

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Changelog: None Do not include in changelog stable backport potential The bug might be minimal and/or import enough to be port to stable type: qa Issues and PRs that relate to testing and code quality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants