🏗️ More Object-Oriented Wrapper for QDMI

[ystade]

As already mentioned in https://github.com/Munich-Quantum-Software-Stack/QDMI/pull/65#pullrequestreview-2397612011, a more object-oriented wrapper in C++ might be handy to work with QDMI. The current state can be inspected in https://github.com/Munich-Quantum-Software-Stack/QDMI/tree/develop/examples/fomac/example_fomac.hpp#L1-L20.

[burgholzer]

Just noting this here so that it doesn't get lost: This is probably exactly what a FoMaC (Figures of Merit and Constraints) library could/should provide. As such, this does not (and maybe should not) necessarily belong in this repository here and rather belongs in its own fomac repository.

In a similar line of thought, QDMI Python bindings will probably be relevant in the future for easier prototyping from Python. At the same time, I would not like to bring Python into the repository here and much rather would provide that through a different channel. How this connects to the object-oriented wrapper? I believe that it could be much easier to bind that to Python via libraries like pybind11 or nanobind.

In general, I believe the current example_fomac hits the right level of abstraction that can be provided and illustrated as part of this repository.

[echavarria-lrz]

@mnfarooqi

[mnfarooqi]

@echavarria-lrz We can keep the QDMI Client Python bindings with our internal QDMI driver implementation. Later we can move it here if it is decided to include support for languages other than C.

[burgholzer]

Later we can move it here if it is decided to include support for languages other than C.

Note that QDMI as an interface already supports various languages other than C. It is merely the language of the interface (the API and ABI) that is C and will stay this way.

Even at this moment, the repository examples demonstrate how to implement devices in C++ in addition to C and how to use QDMI from C++ (example_fomac and example_tool). In a similar fashion, QDMI can already be used from other languages such as Python (for example using ctypes https://docs.python.org/3/library/ctypes.html) or Rust (see https://doc.rust-lang.org/nomicon/ffi.html for example). Although, it is clear that the use from other languages can (and will) be made more accessible in the future.

[mnfarooqi]

In other words by support I mean to facilitate different levels of end users (QDMI clients), as the community grows, to quickly implement their tools/proofs of concepts instead of spending effort writing Python bindings/language wrappers.

PS: These don't have to be in the QDMI repository, they can be in another repo under MQSS.

[burgholzer]

In other words by support I mean to facilitate different levels of end users (QDMI clients), as the community grows, to quickly implement their tools/proofs of concepts instead of spending effort writing Python bindings/language wrappers.

PS: These don't have to be in the QDMI repository, they can be in another repo under MQSS.

Fully agree! I would assume that the MQT will be leading the way here as we plan to incorporate QDMI really soon into our repositories. Given how some of our repositories are pure Python, we definitely will need bindings for that. I would see this as the perfect playground/testbed that could then be fed back into the MQSS ecosystem.

[wnbts]

has QDMI python binding work started somewhere? if not, is there a plan/roadmap for it?

[burgholzer]

has QDMI python binding work started somewhere? if not, is there a plan/roadmap for it?

It has not yet started. I plan to start working on it next week. I'll make sure to update this thread with any pointers.

[echavarria-lrz]

@mnfarooqi: I think you are also working on this, right? Could you kindly coordinate with @burgholzer?

[mnfarooqi]

@mnfarooqi: I think you are also working on this, right? Could you kindly coordinate with @burgholzer?

Yes, I am working on it and I will get in touch with Lukas about it.

[ystade]

I have closed this issue now as I see the tendency to put the functionality in another repository.