qiskit-ibm-runtime
qiskit-ibm-runtime copied to clipboard
Add QPY Version negotation and remove vendored `qiskit.qpy` fork
What is the expected feature or enhancement?
In qiskit 1.0.0 a new kwarg version
was added to the qiskit.qpy.dump()
function (see: https://github.com/Qiskit/qiskit/pull/11644 for the implementation). This flag enables the qiskit.qpy.dump()
function to emit QPY at older versions. This can go back to the minimum compatibility version, which for the 1.x release series is QPY version 10 (which is the version emitted by Qiskit 0.45.x and 0.46.x). This means we no longer need to keep a vendored fork of the qpy module in qiskit-ibm-runtime
because we can rely on the qiskit dump()
function to emit an older version for us instead of purposefully holding back the qpy version via a fork.
However, besides just deleting the fork, this opens up the opportunity to do version negotiation between the client and server side. Qiskit has two attributes qiskit.qpy.QPY_VERSION
and qiskit.qpy.QPY_COMPATIBILITY_VERSION
which represent the maximum and minimum QPY dump
versions (load()
supports all versions up to QPY_VERSION
) supported by the installed qiskit (all the intermediate versions are supported too). If we were to add a an API that returned the maximum supported QPY version on the server side, then qiskit-ibm-runtime
would be capable of determining what value it should set the version
kwarg on qiskit.qpy.dump()
to to ensure that the submitted QPY payload is compatible with the server. However, even if there isn't an API to query the QPY supported versions at first, we can still delete the fork and just manually the version
flag.
Acceptance criteria
Whenever we're ready to set the qiskit requirement to qiskit>=1.0.0
. For the version negotiation piece we'll need a new API to expose the maximum QPY format version accepted by the server.
I pushed up #1377 which handles the first half of this and deletes the vendored copy of qpy. The qpy version emitted is still hard-coded though and to use newer qpy versions we'll need to publish new releases that bump the version used. I didn't mark #1377 as closing this because ideally we'd have version negotiation which can set the version dynamically. But to accomplish this we'll need server side changes.
this opens up the opportunity to do version negotiation between the client and server side
This is awesome!