qiskit

Author SHA1 Message Date

Author	SHA1	Message	Date
Matthew Treinish	75d66dd8ba	Add support for Python 3.11 (#9028 ) * Add support for Python 3.11 Python 3.11.0 was released on 10-24-2022, this commit marks the start of support for Python 3.11 in qiskit. It adds the supported Python version in the package metadata and updates the CI configuration to run test jobs on Python 3.11 and build Python 3.11 wheels on release. * Fix inspect.Parameter usage for API change in 3.11 Per the Python 3.11.0 release notes inspect.Parameter now raises a ValueError if the name argument is a Python identifier. This was causing a test failure in one case where a parameter named `lambda` was used. This commit adjusts the parameter name in the tests to be lam to avoid this issue. * Set a version cap on the jax dev requirement Currently jax doesn't publish Python 3.11 wheels which is blocking test runs with python 3.11. Since jax is an optional package only used for the gradient package we can just skip it as isn't a full blocker for using python 3.11. This commit sets an environment marker on the jax dev requirements to only try to install it on Python < 3.11. * Set python version cap on cplex in CI * DNM: Test wheel builds work * Skip tests on i686/win32 wheel buids with python 3.11 * Revert "DNM: Test wheel builds work" This reverts commit `725c21b465`. * Run QPY backwards compat tests on trailing edge Python version This commit moves the qpy backwards compatibility testing from the leading edge python version, which in this PR branch is Python 3.11, to the trailing edge Python version which is currently 3.7. Trying to add support for a new Python version has demonstrated that we can't use the leading edge version as historical versions of Qiskit used to generate old QPY payloads are not going to be generally installable with newer Python versions. So by using the trailing edge version instead we can install all the older versions of Qiskit as there is Python compatibility for those Qiskit versions. Eventually we will need to raise the minimum Qiskit version we use in the QPY tests, when Python 3.9 goes EoL in October 2025 and Qiskit Terra 0.18.0 no longer has any supported versions of Python it was released for. We probably could get by another year until Python 3.10 goes EoL in 2026 it just means we're building 0.18.x and 0.19.x from source for the testing, but when Python 3.11 becomes our oldest supported version we'll likely have to bump the minimum version. This does go a bit counter to the intent of the test matrix to make the first stage return fast and do a more through check in the second stage. But, in this case the extra runtime is worth the longer term stability in the tests. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>	2022-11-03 16:58:14 +00:00
Jake Lishman	fd46fd154f	Overhaul Azure Pipelines configuration (#7698 ) * Overhaul Azure Pipelines configuration This restructures our monolithic `azure-pipelines.yml` file into a modular setup that separates the logic of specifying "what to run" from "how to run". For example, the different processes for running the Python tests on Linux, Mac and Windows are separated out into three template files, which are then called by the "branch push" and "PR sync" pipeline files in a few different stages. This is also to centralise the logic for "how to run"; previously, it was duplicated in a few different stages. There are also major changes to content of "what to run". Branch push: This now only runs a single Linux test, just as a sanity check. Previously it ran the full PR CI suite, including lint, docs, tutorials, and the entire Python testing matrix. This was unnecessary, as the branch protection rules and PR merge strategy ensured that the code must already have been up-to-date and passed the PR CI before it could be pushed to the branch, so was simply burning CI resources for no benefit. To the best of my knowledge, the branch-push CI had never caught a bug. PR sync: This remains split into two stages, but now only the oldest and newest Python versions are tested, rather than the entire matrix. It is exceedingly rare (I'm not sure it's ever happened) that a commit breaks an intermediate Python version _only_, so instead we add a new "nightly" CI run to test the full matrix, which should be sufficient to catch these. The "preliminary" stage is reduced to lint, docs and a single test run; about half of PR commits cause a CI failure, and over 90% of these would be caught by the new structure. The second stage contains the tutorials and the rest of the `{oldest,newest},{windows,mac,linux}` matrix. This is to reduce total CI load, with the intent that failing runs should almost universally fail just as quickly as they did before. Nightly: Entirely new. This is tests of the full matrix of Python versions and OSes for the `main` and `stable` branches, if a given branch was updated since the last run. It should be very unlikely that this run catches errors. Tag push: The deployment process is unchanged, just refactored into a format for easier management. * Refactor split pipelines into single entry point This maintains the same logical splits as the previous commit, but rather than using four separate pipeline files, it uses template conditional compilation to put them in a single large file. This lets us keep continuity with our current Azure setup, and lets us easily share a series of configuration variables (including a general YAML object) between the different stages. This commit swaps from using a `strategy: matrix` in the test jobs, in favour of using templated loops over the variables from the main `azure-pipelines.yml` file. This is because passing strings like `"3.10"` contained within YAML arrays from one template file to another appears to trigger some sort of implicit conversion somewhere, and `"3.10"` can be interpreted as `3.1`. * Leave comment on nightly testing failure * Reinstate autocancel * Quote string parameters Co-authored-by: Kevin Hartman <kevin@hart.mn> * Split long environment variable Co-authored-by: Kevin Hartman <kevin@hart.mn> * Add more comments on YAML syntax * Add option to install from sdist in Linux tests Co-authored-by: Kevin Hartman <kevin@hart.mn>	2022-04-13 19:45:37 +00:00

Matthew Treinish

75d66dd8ba

Add support for Python 3.11 (#9028 )

* Add support for Python 3.11

Python 3.11.0 was released on 10-24-2022, this commit marks the start of
support for Python 3.11 in qiskit. It adds the supported Python version in
the package metadata and updates the CI configuration to run test jobs
on Python 3.11 and build Python 3.11 wheels on release.

* Fix inspect.Parameter usage for API change in 3.11

Per the Python 3.11.0 release notes inspect.Parameter now raises a
ValueError if the name argument is a Python identifier. This was causing a
test failure in one case where a parameter named `lambda` was used.
This commit adjusts the parameter name in the tests to be lam to avoid
this issue.

* Set a version cap on the jax dev requirement

Currently jax doesn't publish Python 3.11 wheels which is blocking test
runs with python 3.11. Since jax is an optional package only used for
the gradient package we can just skip it as isn't a full blocker for
using python 3.11. This commit sets an environment marker on the jax
dev requirements to only try to install it on Python < 3.11.

* Set python version cap on cplex in CI

* DNM: Test wheel builds work

* Skip tests on i686/win32 wheel buids with python 3.11

* Revert "DNM: Test wheel builds work"

This reverts commit 725c21b465.

* Run QPY backwards compat tests on trailing edge Python version

This commit moves the qpy backwards compatibility testing from the
leading edge python version, which in this PR branch is Python 3.11, to
the trailing edge Python version which is currently 3.7. Trying to add
support for a new Python version has demonstrated that we can't use the
leading edge version as historical versions of Qiskit used to generate
old QPY payloads are not going to be generally installable with newer
Python versions. So by using the trailing edge version instead we can
install all the older versions of Qiskit as there is Python
compatibility for those Qiskit versions. Eventually we will need to
raise the minimum Qiskit version we use in the QPY tests, when Python
3.9 goes EoL in October 2025 and Qiskit Terra 0.18.0 no longer has any
supported versions of Python it was released for. We probably could
get by another year until Python 3.10 goes EoL in 2026 it just means
we're building 0.18.x and 0.19.x from source for the testing, but when
Python 3.11 becomes our oldest supported version we'll likely have to
bump the minimum version.

This does go a bit counter to the intent of the test matrix to make the
first stage return fast and do a more through check in the second stage.
But, in this case the extra runtime is worth the longer term stability
in the tests.

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

2022-11-03 16:58:14 +00:00

Jake Lishman

fd46fd154f

Overhaul Azure Pipelines configuration (#7698 )

* Overhaul Azure Pipelines configuration

This restructures our monolithic `azure-pipelines.yml` file into a
modular setup that separates the logic of specifying "what to run" from
"how to run".  For example, the different processes for running the
Python tests on Linux, Mac and Windows are separated out into three
template files, which are then called by the "branch push" and "PR sync"
pipeline files in a few different stages.  This is also to centralise
the logic for "how to run"; previously, it was duplicated in a few
different stages.

There are also major changes to content of "what to run".

    Branch push:
        This now only runs a single Linux test, just as a sanity check.
        Previously it ran the full PR CI suite, including lint, docs,
        tutorials, and the entire Python testing matrix.  This was
        unnecessary, as the branch protection rules and PR merge
        strategy ensured that the code must already have been up-to-date
        and passed the PR CI before it could be pushed to the branch, so
        was simply burning CI resources for no benefit.  To the best of
        my knowledge, the branch-push CI had never caught a bug.

    PR sync:
        This remains split into two stages, but now only the oldest and
        newest Python versions are tested, rather than the entire
        matrix.  It is exceedingly rare (I'm not sure it's ever
        happened) that a commit breaks an intermediate Python version
        _only_, so instead we add a new "nightly" CI run to test the
        full matrix, which should be sufficient to catch these.  The
        "preliminary" stage is reduced to lint, docs and a single test
        run; about half of PR commits cause a CI failure, and over 90%
        of these would be caught by the new structure.  The second stage
        contains the tutorials and the rest of the
        `{oldest,newest},{windows,mac,linux}` matrix.  This is to reduce
        total CI load, with the intent that failing runs should almost
        universally fail just as quickly as they did before.

    Nightly:
        Entirely new.  This is tests of the full matrix of Python
        versions and OSes for the `main` and `stable` branches, if a
        given branch was updated since the last run.  It should be very
        unlikely that this run catches errors.

    Tag push:
        The deployment process is unchanged, just refactored into a
        format for easier management.

* Refactor split pipelines into single entry point

This maintains the same logical splits as the previous commit, but
rather than using four separate pipeline files, it uses template
conditional compilation to put them in a single large file.  This lets
us keep continuity with our current Azure setup, and lets us easily
share a series of configuration variables (including a general YAML
object) between the different stages.

This commit swaps from using a `strategy: matrix` in the test jobs, in
favour of using templated loops over the variables from the main
`azure-pipelines.yml` file.  This is because passing strings like
`"3.10"` contained within YAML arrays from one template file to another
appears to trigger some sort of implicit conversion somewhere, and
`"3.10"` can be interpreted as `3.1`.

* Leave comment on nightly testing failure

* Reinstate autocancel

* Quote string parameters

Co-authored-by: Kevin Hartman <kevin@hart.mn>

* Split long environment variable

Co-authored-by: Kevin Hartman <kevin@hart.mn>

* Add more comments on YAML syntax

* Add option to install from sdist in Linux tests

Co-authored-by: Kevin Hartman <kevin@hart.mn>

2022-04-13 19:45:37 +00:00

2 Commits