QPY Qiskit 1.0 updates

[kt474]

Summary

Credit goes to:

Qiskit/qiskit#10902
Qiskit/qiskit#11260
Qiskit/qiskit#11522
Qiskit/qiskit#11403
Qiskit/qiskit#11495
Qiskit/qiskit#11488

Qiskit/qiskit#11647
Qiskit/qiskit#11646
Qiskit/qiskit#11644
Qiskit/qiskit#11505

Details and comments

Fixes #1338

[ElePT]

Hi @kt474, I see a few 1.0 QPY changes not reflected in this PR, they were last-minute changes so I'm bringing them to your attention in case they had slipped under your radar (if not, feel free to ignore):

• Add uuid property to Parameter qiskit#11647 (affects qpy)
• Handle custom operations with overlapping names in QPY qiskit#11646
• Add version flag to qpy dump qiskit#11644

[mtreinish]

There's also: Qiskit/qiskit#11505

[mtreinish]

FWIW, I just opened #1375 to track deleting the fork of the qpy module here. In qiskit 1.0.0 we added the necessary functionality to cover emitting older versions of the QPY format from qiskit.qpy.dump(). However, we obviously can't remove the fork until we're ready to set the qiskit dependency to >=1.0.0

[jyu00]

Would this work with pre-1.0 QPY? Because the server is still at 0.*

[mtreinish]

Would this work with pre-1.0 QPY? Because the server is still at 0.*

Yes, there is specifically overlap in the versions supported by dump() to enable this. The minimum qpy compatibility version is 10 in the 1.x series, which is the version dump() emits by qiskit 0.45.x and 0.46.x and is the maximum version load() supports in 0.45.x and 0.46.x. I outlined a few of the details in #1375 on how ideally we can do version negotiation if there is an API we can query to either figure out what the maximum qpy version is supported by the server (or alternatively which qiskit version is deployed)

[kt474]

@mtreinish to be compatible with 0.45, this is causing an error

AttributeError: 'ParameterVectorElement' object has no attribute 'uuid'

Because uuid is added as an attribute to Parameter here, only in 1.0

How should this be handled here?

[mtreinish]

Fully porting the qpy changes from qiskit 1.0.0rc1 will inherently be unsound for use with qiskit 0.45.0 or 0.46.0. The internals of the qpy module are updated in lock-step with the QuantumCircuit class. This is basically the same underlying issue we hit that needed: Qiskit/qiskit-ibm-provider#757

This will also start emitting qpy version 11 which will cause a version mismatch with what the server side can parse until it is upgraded to qiskit 1.0.0. I pushed up: #1377 as an alternative to this which will let you do the upgrade in a manner which is compatible with both versions so you can publish a release that is both 0.45.x/0.46.x and 1.0.0 compatible. It also removes the vendored fork completely as it is not needed anymore (and luckily has never been released either, so there is no backwards compatibility issue).

[kt474]

Got it, thank you so much for taking care of this!

I'll close this PR

[kt474]

I'll create a PR to do the same in qiskit-ibm-provider (but we can't remove the fork completely yet)

[1ucian0]

@mtreinish wrote #1377 as an alternative to this PR. 1377 handles QPY in a way that supports qiskit 0.45/0.46 and 1.0.