Add conversion between `jeff` and Qiskit

[denialhaag]

Description

To ensure compatibility with the greater ecosystem, it would be nice to have conversions between jeff and Qiskit.

A first version of these conversions does not need to cover jeff's full capabilities. A minimal implementation should be able to round-trip most, if not all, straight-line quantum programs.

As a starting point, consider the following circuit (taken from Qiskit's documentation):

qr = QuantumRegister(2, "q")
cr = ClassicalRegister(2, "c")
qc = QuantumCircuit(qr, cr)

qc.x([0, 1])
qc.h(0)
qc.cx(0, 1)
qc.ry(-2 * pi / 3, 1)
qc.measure([0, 1], [0, 1])

Given the limited scope, it should be possible to implement the conversions using Qiskit's new C API in combination with the C++ builder.

Acceptance criteria

• Most straight-line quantum programs can be round-tripped
• Implementation builds on Qiskit's C API

Out-of-scope follow-ups

Support for all of jeff's operations can be added in follow-up issues.

[burgholzer]

It should be possible to roundtrip most (if not all) straight-line circuits.
As soon as classical computations are involved, it may become a little trickier or support may need to be limited at first.

As for the language question: The C-API of qiskit may be a good target here, as its scope is currently fairly limited compared to the Rust and Python APIs.
Building on top of the C-API could allow us to incrementally evolve the conversions as the C-API evolves.

Just my 2ct's though

[denialhaag]

It should be possible to roundtrip most (if not all) straight-line circuits. As soon as classical computations are involved, it may become a little trickier or support may need to be limited at first.

As for the language question: The C-API of qiskit may be a good target here, as its scope is currently fairly limited compared to the Rust and Python APIs. Building on top of the C-API could allow us to incrementally evolve the conversions as the C-API evolves.

Just my 2ct's though

Thanks for the feedback! I have updated the issue accordingly. 🙂

[Anshhhhh-chand]

Hi @denialhaag @burgholzer! 👋 I've just opened a PR for this issue here: #69

I noticed the architectural concerns raised in previous attempts (like #64), so I took a different approach to ensure this aligns natively with the project's ecosystem.

How this implementation is different: Rather than relying on pure-Python wrappers or incurring the overhead of bridging Python objects, I built the bidirectional converter natively in C++ (tools/qiskit_convert) utilizing the Qiskit C API.

The logic interacts directly with QkCircuit structs and handles parameterized gates (float.const64), accurate qubit allocation/freeing, and measurements smoothly at the C++ level.
I wrapped this native C++ core into a Python C-extension (qiskit_jeff_py.so) using Qiskit's qk_circuit_borrow_from_python. This gives users the best of both worlds: high-performance native parsing, with a seamless Python API for testing and ecosystem integration.

I also added comprehensive pytest round-trip validations to guarantee structural equivalence.

I'd love to get your feedback on this approach! Please let me know if there are any adjustments needed. Thanks!