Qiskit-terra: C++ QASM Simulator as a Debian Package

Created on 20 May 2018 · 3Comments · Source: Qiskit/qiskit-terra

In order to use the simulator, the only option available right now is to download this entire repository and compile it. However, not in all cases we are also interested in using the Python SDK, for example, if we want use another framework like the one for Swift. So, it would be nice to have another way to install the QASM simulator ... for Linux (other platforms, like macOS, we can discuss later :) ).

Expected Behavior

apt-get install qasm-simulator-cpp
./qasm_simulator_cpp input.json

Current Behavior

git clone https://github.com/QISKit/qiskit-sdk-py.git
cd qiskit-sdk-py
make depends
make sim
cd out/src/qasm-simulator-cpp
./qasm_simulator_cpp input.json

Possible Solution

I have already prepared the package and it is available here: https://github.com/indisoluble/qasm-simulator-cpp-debian-pkg.
Now I have to find a sponsor but, for this to be possible, I need to confirm a couple of things:

Do you agree with packaging this software?
If the answer is yes, I would be the maintainer of this package, would this be OK?

Context

I opened the following issue in the QISKit repository for Swift to discuss how we could integrate the QASM simulator in the Swift framework: Plan to integrate C++ simulator. I suggested the first step should be to provide an easy way to install the simulator but this plan can not go through unless you agree ... hopefully you will :)

Source

indisoluble

Most helpful comment

Hi @indisoluble,
Probably the best course of action is to move the packaging code to salsa.debian.org (I agree, the DebianScience place seems like the correct place) and work on packaging qiskit for Debian in multiple binaries, one of them can be the simulator. I can sponsor it (I'm [email protected]).
Since the issue is tracked in the BTS and is not a QISKit (as upstream) issue. I'm closing it.

Thanks for pushing the effort, luciano

1ucian0 on 22 May 2018

👍2

All 3 comments

Hello @indisoluble - and thanks for the suggestion and for the effort so far! We actually had some internal conversations about packaging qiskit (this Python SDK) for Debian, as we currently have a couple of people involved with Debian in the team (that would be me, as a low activity maintainer mostly at the DPMT, and @1ucian0 , as a fully fledged Debian developer!) and we would be happy to have it in the Debian repositories. As a matter of fact, a RFP was issued by Luciano, although it was not followed up with high priority as the idea was to work on it after the 0.5 release.

The lowering of the priority is also partly related to the C++ simulator - as you noticed, currently we are building the C++ as a single binary that is invoked when needed, but in the short term we are planning to include it as a proper compiled extension more integrated with Python (which should also simplify the packaging effort). We still do plan to keep the option for compiling it as a standalone binary, as it might be useful in some cases - for example, (and me not being familiar with the Swift ecosystem), it seems it would fit that case as well if indeed Swift packages that mix languages are not possible.

As for the packaging of the simulator itself: yes, we would love to have it packaged! Being a maintainer yourself shouldn't be a problem at all, however, could you look into the possibility of joining an existing team that might be suitable, and allow for maintaining it in a collaborative manner (Debian Science comes to mind)? Hopefully Luciano will be able to elaborate - it's not mandatory at all (and if no team seems appropriate, there are other options, such as multiple maintainers or NMUs), it's mostly for sharing the workload and ensuring we are able to keep the package in sync with the latest releases eventually. Please let us know if any help is needed navigating the Debian procedures, but usually all starts with an ITP :)

In the technical front, after peeking a bit at your repository, please note we currently have a cmake-based system in place that we actually use when building the Python packages (and compiling the binary as as a step). While the existing plain Makefile should also do the trick, it might be a good idea to try to make use of the cmake build system, as one of the benefits is that it should cope better with differences in architectures and compilers, and ease the amount of work needed when packaging for multiple platforms.

TL;DR: looking forward to it :+1: