search

Qiskit / qiskit-ibm-runtime

IBM Client for Qiskit Runtime
https://docs.quantum.ibm.com/api/qiskit-ibm-runtime
Apache License 2.0
149 stars 154 forks source link

Add QPY Version negotation and remove vendored `qiskit.qpy` fork #1375

Open mtreinish opened 7 months ago

mtreinish commented 7 months ago

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.

mtreinish commented 7 months ago

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.

jyu00 commented 7 months ago

this opens up the opportunity to do version negotiation between the client and server side

This is awesome!