This repository has been archived by the owner on Jul 24, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 68
Enable support for 0.45.0rc1 with QPY version 9 #757
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The qiskit-ibm-provider package maintains a fork of the QPY serialization module from upstream qiskit. This is done primarily because Qiskit only supports writing a single qpy format version per release (whatever the most recent is). However, since the server side of the ibm runtime version does not always support the latest QPY format version immediately and tends to lag a bit behind what upstream Qiskit is emitting. The fork in qiskit-ibm-provider is used to control the QPY format version that is used for job submission so it ensure the leading edge only moves as quickly as the server side is updated. However, for the upcoming qiskit 0.45.0 release there were some internal object model changes and the fork of qpy (which is a copy of the qpy module from qiskit-terra 0.25.x/qiskit 0.44.x) is incompatible with those changes. This results in errors during the serialization because the qpy module is trying to serialize the circuit with assumptions of the code that do not hold with the upcoming 0.45.0 release. To further complicate matters qiskit 0.45.0 also introduced QPY version 10 which is completely incompatible with version 9 being used by the ibm runtime currently. This means the normal strategy of porting all the changes from qiskit during the upcoming release to the provider isn't viable in the short term, at least until the server side is updated to support QPY version 10. To address this compatibility in the short term, this commit is a partial backport of the changes made in qiskit 0.45.0 to the qpy module, but only those changes made to accomodate the internal qiskit changes during the release. It's also done in a manner where it doesn't require the 0.45.0 release, so that the provider can be used with either qiskit 0.44.x and 0.45.0. However, this is only a short term solution, once the server side is updated to support QPY we should use Qiskit#736 and release a new minor version of the provider package to just use QPY format version 10. This commit is explicitly only for the 0.7.x release series and is being proposed directly to the stable/0.7 branch. For 0.8.0 Qiskit#736 will port over the upstream changes to QPY including QPY format version 10 which is a more sustianable fix longer term. But this is blocked until the server side has support for QPY format version 10. To simplify the dependency tree, and to enable users to submit ibm runtime jobs using 0.45.0rc1 this targets solely compatibility between qiskit 0.45.0 and qiskit-ibm-provider 0.7.x. Fixes Qiskit#755
+1 for getting this quickly into a patch release to unblock work requiring new features. |
kt474
approved these changes
Oct 24, 2023
I'll get a patch release out tmrw that will include this update, |
Pull Request Test Coverage Report for Build 6634325530
💛 - Coveralls |
This was referenced Oct 25, 2023
dieris
pushed a commit
to dieris/qiskit-ibm-provider
that referenced
this pull request
Dec 12, 2023
The qiskit-ibm-provider package maintains a fork of the QPY serialization module from upstream qiskit. This is done primarily because Qiskit only supports writing a single qpy format version per release (whatever the most recent is). However, since the server side of the ibm runtime version does not always support the latest QPY format version immediately and tends to lag a bit behind what upstream Qiskit is emitting. The fork in qiskit-ibm-provider is used to control the QPY format version that is used for job submission so it ensure the leading edge only moves as quickly as the server side is updated. However, for the upcoming qiskit 0.45.0 release there were some internal object model changes and the fork of qpy (which is a copy of the qpy module from qiskit-terra 0.25.x/qiskit 0.44.x) is incompatible with those changes. This results in errors during the serialization because the qpy module is trying to serialize the circuit with assumptions of the code that do not hold with the upcoming 0.45.0 release. To further complicate matters qiskit 0.45.0 also introduced QPY version 10 which is completely incompatible with version 9 being used by the ibm runtime currently. This means the normal strategy of porting all the changes from qiskit during the upcoming release to the provider isn't viable in the short term, at least until the server side is updated to support QPY version 10. To address this compatibility in the short term, this commit is a partial backport of the changes made in qiskit 0.45.0 to the qpy module, but only those changes made to accomodate the internal qiskit changes during the release. It's also done in a manner where it doesn't require the 0.45.0 release, so that the provider can be used with either qiskit 0.44.x and 0.45.0. However, this is only a short term solution, once the server side is updated to support QPY we should use Qiskit#736 and release a new minor version of the provider package to just use QPY format version 10. This commit is explicitly only for the 0.7.x release series and is being proposed directly to the stable/0.7 branch. For 0.8.0 Qiskit#736 will port over the upstream changes to QPY including QPY format version 10 which is a more sustianable fix longer term. But this is blocked until the server side has support for QPY format version 10. To simplify the dependency tree, and to enable users to submit ibm runtime jobs using 0.45.0rc1 this targets solely compatibility between qiskit 0.45.0 and qiskit-ibm-provider 0.7.x. Fixes Qiskit#755 Co-authored-by: Kevin Tian <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
The qiskit-ibm-provider package maintains a fork of the QPY serialization module from upstream qiskit. This is done primarily because Qiskit only supports writing a single qpy format version per release (whatever the most recent is). However, since the server side of the ibm runtime does not always support the latest QPY format version immediately and tends to lag a bit behind what upstream Qiskit is emitting this can cause issues for users who upgrade to the latest qiskit quickly. The fork in qiskit-ibm-provider is used to control the QPY format version that is used for job submission so it ensure the leading edge only moves as quickly as the server side is updated. However, for the upcoming qiskit 0.45.0 release there were some internal object model changes and the fork of qpy (which is a copy of the qpy module from qiskit-terra 0.25.x/qiskit 0.44.x) is incompatible with those changes. This results in errors during the serialization because the qpy module is trying to serialize the circuit with assumptions of the code that do not hold with the upcoming 0.45.0 release. To further complicate matters qiskit 0.45.0 also introduced QPY version 10 which is completely incompatible with version 9 being used by the ibm runtime currently. This means the normal strategy of porting all the changes from qiskit during the upcoming release to the provider isn't viable in the short term, at least until the server side is updated to support QPY version 10.
To address this compatibility in the short term, this commit is a partial backport of the changes made in qiskit 0.45.0 to the qpy module, but only those changes made to accomodate the internal qiskit changes during the release. It's also done in a manner where it doesn't require the 0.45.0 release, so that the provider can be used with either qiskit 0.44.x and 0.45.0. However, this is only a short term solution, once the server side is updated to support QPY we should use #736 and release a new minor version of the provider package to just use QPY format version 10.
This commit is explicitly only for the 0.7.x release series and is being proposed directly to the stable/0.7 branch. For 0.8.0 #736 will port over the upstream changes to QPY including QPY format version 10 which is a more sustianable fix longer term. But this is blocked until the server side has support for QPY format version 10. To simplify the dependency tree, and to enable users to submit ibm runtime jobs using 0.45.0rc1 this targets solely compatibility between qiskit 0.45.0 and qiskit-ibm-provider 0.7.x.
Details and comments
Fixes #755