ROOT6 C++ Jupyter kernel

[hansgans]

Problem:

ROOT6 has a C++ Jupyter kernel which relies on python metakernel (​https://pypi.python.org/pypi/metakernel). Unfortunately MacPorts does not provide a package for this. This kernel is different from using pyroot within Jupyter (see Bug report #54694).

Solution:

Installation of metakernel via pip works like a charm. Would be great to have a MacPorts package for metakernel and a dependency of root on it.

Improvement

Currently the ROOT packages does not have a dependency on Jupyter packages. One could probably think of a ROOT package variants +jupyter which introduces those dependencies.

[mojca (Mojca Miklavec)]

We should really split python code from the rest. Then we could install py27-root6 and py36-root6 at the same time and add dependencies without having to introduce variants just to add a dependency. Variant means that if you want to install it, it will have to be compiled from source.

[mojca (Mojca Miklavec)]

Can you help convincing upstream to provide a way to install the python package independent from building the cling monster?

[hansgans]

I don't think it is possible to separate the root python code from the rest. My suggestion would be to add the necessary dependencies to the existing variant +pythonXY (including metakernel which is not yet exist as a MacPorts package).

[mojca (Mojca Miklavec)]

Replying to hansgans:

I don't think it is possible to separate the root python code from the rest.

It might not be possible to compile separately as of this very moment, but I see not technical reason why support for that couldn't be written. We should just try to push the developers a bit. For MacPorts being able to do this would be a super valuable addition because we could then support all python versions very easily.

I guess we could still write python subports that would install the complete root with support for python version X and then delete the rest of root. This would be super annoying to compile on your own machine, but if you get a binary package from the server, that should in principle work nicely and users could install support for multiple versions of python.

(It would also be helpful if it was possible to compile cling separately from root, but that's a totally different issue.)

[hansgans]

Replying to mojca:

Replying to hansgans:

I don't think it is possible to separate the root python code from the rest.

It might not be possible to compile separately as of this very moment, but I see not technical reason why support for that couldn't be written. We should just try to push the developers a bit. For MacPorts being able to do this would be a super valuable addition because we could then support all python versions very easily.

From pyroot you can call (almost) any library of ROOT. Therefore, it depends almost on any root library. So I do not see how you can compile a working version of pyroot without almost all the rest (of course would be nice to exclude cling).

I guess we could still write python subports that would install the complete root with support for python version X and then delete the rest of root. This would be super annoying to compile on your own machine, but if you get a binary package from the server, that should in principle work nicely and users could install support for multiple versions of python.

If that works that would be great! But if you have a root shared library in lib/ that depends on python, how can you install multiple versions of it?

[hansgans]

btw. if I want to have metakernel as MacPort package. Where can I ask for it? Should I create a bug report?

[mojca (Mojca Miklavec)]

Sure, one still needs a complete ROOT installation in order to run it from Python. But the difference is that having a separate port would enable us to install ROOT without python support first, and then install python support for any given version of Python, possibly for multiple versions, in a very efficient way, with short compilation time.

At the moment one has to recompile cling just for the sake of switching to a different python version than built by the buildbot.

If you want a new package, you can of course open a Trac ticket, but the chances someone will pick this up are super slim unless others need it as well.

By far the best way to get a package is to try to create it yourself and then submit a pull request. If you are stuck, just ask on the mailing list (macports-dev) or on IRC for help. Since metakernel is hosted on pypi, the easiest way to create a package is to run ​pypi2port (you can also install it with sudo port install pypi2port, but that one is slightly outdated), check whether any additional dependencies are needed or perhaps some other modifications, create a local repository, test the port and then submit a pull request. In the long run you can gradually learn the process and once you are able to do arbitrary modifications, that greatly simplifies your life :)

[Schamschula (Marius Schamschula)]

I just added py-metakernel to the macports-ports repository (as it is also needed by py-octave_kernel):

​https://github.com/macports/macports-ports/commit/1445b0e631a773ed0a2a70751912ce4d25115f60

[hansgans]

Great! Thank you!

[cjones051073 (Chris Jones)]

metakernel now added as a dependency too root6 as part of the python variant.