Is SlicerJupyter broken on macOS due to argon2-cffi (again?)


This problem was mentioned here on the forum a couple of times already and some fixes that were made actually worked just a month ago.

Forum posts:

Commit that addressed the issue

I was using Jupyter Lab inside Slicer in December and January. To my big surprize when I tried to setup a jupyter environment in the freshly downloaded Nightly build the problem came back.
Jupyter notebook server doesn’t launch from inside slicer and jupyter lab cannot be installed because it can’t build argon2-cffi.
So the workaround of installing an older version of notebook (6.0.3) works for the notebook server and Jupyter Lab can be installed after that, but now it stopped running. So the workaround doesn’t work any more.

File "/Applications/MedicalImaging/", line 421, in _init_posix
    _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0)
ModuleNotFoundError: No module named '_sysconfigdata__darwin_darwin'
Traceback (most recent call last):

The funny thing that just about a month ago I was simply running jupyterlab inside slicer with all the nice plugins working “out of the box”.

What would be the advice to solve this? Build, maintain and manually install the macOS wheels for python3.6 or wait a little because support for python 3.7+ is coming during in some foreseeable future?
Maybe there is some other solution?

For argon2-cffi specifically, there are only wheels available on PyPI for Python 2.7 and Python 3.7 specifically. In the forseeable future we would be updating to probably the latest stable release of Python which is 3.9 at the moment. Therefore I don’t think you’re going to have any long term success installing this package with a wheel from PyPI on macOS. It doesn’t appear that is priority for maintainers of that package to create wheels on Intel mac or Apple silicon mac.

I’m not sure what the factory build machine is doing to manually build argon2-cffi and what the macOS compatibility is for the wheel it is making. @lassoan Was it built manually on the factory?

Thanks for the input @jamesobutler
I don’t run into argon2-cffi issues when using jupyter lab for data science tasks in python 3.9 outside slicer. I use pip in that environment and argon2_cffi-20.1.0-cp37-abi3-macosx_10_6_intel.whl works fine.

A workaround that worked for me just now is to use the Slicer kernel from Jupyter Lab that’s installed outside of Slicer.

I’ve added argon2-cffi Python package to the SlicerJupyter extension In December. I’ve just installed latest Slicer Preview Release on a macOS system and Jupyter server from Slicer’s Python environment (started by the JupyterKernel module) worked well.

Last time I updated xeus it had some incompatibility issues with latest jedi. These issues were resolved, so I now updated xeus and all dependencies to their latest stable version. I’ve tested and it works on Windows. It would be great if you could test SlicerJupyter in the Slicer Preview Release tomorrow on macOS and linux.

1 Like

Hey @lassoan , I’ve just downloaded the .dmg that’s available on Slicer website as the nightly build (version 2020-02-03) and when I install JupyterKernel from the extension manager and press “Launch notebook server” button in the extension UI the error is printed to the python console full log here.

The workaround that works for me on macOS 11.1:

  1. Install JupyterKernel extension
  2. Manually install older version of jupyter notebook via python interpreter (pip_install('notebook=6.0.3'))
  3. Install jupyter lab with all the perks in an environment outside slicer (a brew-python venv for example)
  4. Register a new kernel in the external environment using the command from the JupyterKernel Slicer module UI. The kernel should appear on the launcher page and in kernel selection dropdown menus as Slicer-4.13)
  5. Use the Slicer 4.13 kernel to connect to the slicer environment from Jupyter Lab

I assume that moving to a more recent version of python will fix this issue and this migration is “around the corner”. I would love to help testing this out.

argon2-cffi is included in the extension package.

The regression is caused by the recent update of Slicer that makes is a portable application.

It seems that the launcher converts relative paths to absolute paths differently depending on how Slicer is started. After installing latest Slicer Preview Release and installing SlicerJupyter extension, result of import sys; sys.path is the following:

If you start /⁨Applications⁩/⁨Contents/⁨MacOS⁩ from a terminal:

[’/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’]

If you double-click on Slicer-20210203 in the Finder:

[’/Applications/’, ‘/Extensions-29684/SlicerJupyter/lib/Slicer-4.13/qt-scripted-modules’, ‘/Extensions-29684/SlicerJupyter/lib/python3.6/site-packages’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’, ‘/Applications/’]

Note the incorrect path of site-packages:

  • started from terminal: /Applications/ → there is an extra MacOS
  • started from Finder: /Extensions-29684/SlicerJupyter/lib/python3.6/site-packages → missing /Applications/

Since the site-packages folder path is incorrect, pip cannot to find the existing argon2 package and that’s why it tries to build it.

@jcfr Could you have a look at this? Do you know what can cause the different behavior? Probably this single line needs to be changed but I don’t know how the launcher works on macOS and what would be the proper path to use:

This issue described by @lassoan has been fixed in


Thanks a lot @jcfr!

@pll_llq could you test if Jupyter launches correctly (without the need of setting up an external Python environment) in the Slicer Preview Release that you download tomorrow or later? Thank you.

Hi, Just tested this on 4.13.0-2021-02-11.
There’s no problems with argon2-cffi but the Notebook server didn’t launch.
The pip part of the install process went OK but the launch failed on a later stage (when jupyter tries to enable the ipyevents extension)

subprocess.CalledProcessError: Command '['/Applications/MedicalImaging/', '-m', 'jupyter', 'nbextension', 'enable', '--py', 'ipyevents']' returned non-zero exit status 1.

because of

ImportError: dlopen(/Applications/MedicalImaging/, 1): Library not loaded: @loader_path/../../.dylibs/libzmq.5.dylib
  Referenced from: /Applications/MedicalImaging/
  Reason: Incompatible library version: requires version 8.0.0 or later, but libzmq.5.dylib provides version 5.0.0

Full log here

Look like we need to update zmq library here:

I’ve updated to latest version (v4.3.4) and unfortunately nothing has changed. @jcfr do you have any idea what could be the issue?

I’ve tried to test SlicerJupyter on linux to validate that the problem is mac-only, but on on the latest nightly the extension was not mentioned in the extension manager. Was it taken down, or is there something I’m missing on linux?

p.s. this is a laptop with ubuntu 18

You can monitor the status of all extension builds on the dashboard.

It seems that gcc bails out on some type check (xeus/src/xdap_tcp_client.cpp:192:44: error: no matching function for call to ‘zmq::message_t::message_t(std::string&)’). Probably upgrading xeus or downgrading zmq will fix the issue. I’ll have quick loook.

1 Like

There is a SlicerJupyter build error on the linux factory:

[  7%] Building CXX object CMakeFiles/xeus-static.dir/src/xdap_tcp_client.cpp.o
/.../SlicerJupyter-build/xeus/src/xdap_tcp_client.cpp: In member function ‘void xeus::xdap_tcp_client::init_tcp_socket(const string&)’:
xeus/src/xdap_tcp_client.cpp:192:44: error: no matching function for call to ‘zmq::message_t::message_t(std::string&)’
             m_socket_id = zmq::message_t(id);
In file included from cppzmq/zmq_addon.hpp:27:0,
                 from xeus/src/xdap_tcp_client.cpp:1:

Since I cannot reproduce the error on my linux machine (clean Ubuntu 20.04 install with freshly-built Slicer, with all default options) it is very hard to figure out what exactly is wrong and how to fix it.

@Sam_Horvath Could you have a look at it? The fix may be as simple as adding some constant casting.

Sure, I can take a look at it


Changing this line:


m_socket_id = zmq::message_t(, id.size());

fixes the build error. The breaking change was introduced in SlicerJupyter here:

and in Xeus here:

Why its breaking: not sure. There is a conversion constructor that should handle this:

but it doesn’t seem to be.

1 Like

Thanks a lot @Sam_Horvath, this is exactly the information I needed!

@Sam_Horvath I’m new to this. Cloud you please elaborate on how to solve the problem for mac users?

I also got the error message “Incompatible library version: requires version 8.0.0 or later, but libzmq.5.dylib provides version 5.0.0” when I install “pip_install(‘jupyterlab’)

You mentioned that we could change some lines to upgrade and solve this problem, but actually how to do that? like which file?

Thank you!

Hi, if you like using Jupyter Lab in general (not just for Slicer based research) and you have a Jupyter Lab environment on your local machine that you work with - you can create a Slicer Kernel for that local Jupyter Lab. It will be separate from Slicer but you will be able to use the Slicer environment from there.

This works for me just fine (apart from Jedi code completion being extremely slow on macOS for some reason).

You can install the Slicer kernel using the command that’s generated by the JupyterKernel extension. See the “Jupyter server in external Python environment” section of the module UI.