Installing extensions in binary distribution of Slicer

Upon installing an Extension from ExtensionManager, it appears that ~/.config/NA-MIC/Slicer-{revision}.ini file gets updated with new [LibraryPaths], AdditionalPaths, [PYTHONPATH], [PATH] even though I specify a different directory for Extensions installation path. Is there a way to compartmentalize where Slicer-{revision}.ini file will be written?

The use case is, I have my own Extensions at ~/.config/NA-MIC while there is a shared Extension path at ~/where/ever/it/is. Extensions installed at the latter directory are not found by a different user unless a Slicer-{revision}.ini exists in a shared directory.

I think in this case the easiest solution is to make a shell script that uses the --additional-module-paths command line argument to specify all the extensions.

Okay, but then someone would have to type in all the extensions, right? In @jcfr’s suggestion, it was more or less automatically discovered.

To compartmentalize settings, you can rename the Slicer executable file (bin/SlicerApp-real). This will create custom .ini files completely independent from Slicer installations. You also need to update Application/path value in bin/SlicerLauncherSettings.ini file accordingly.

To have completely isolated, custom-branded applications, you can build Slicer from source using this template.

1 Like

It’s a matter of taste, but there’s a tradeoff here between simplicity and automation. Personally, I think a script that has a lot of identical lines adding paths to the command line is easier to understand and maintain (especially if it’s nicely formatted with backslashes and indentation). There’s only so much that needs to be in such a script.

1 Like

There’s only so much that needs to be in such a script.

I like your thought. Question on that: see the following excerpt from Slicer-28257.ini file:


In the rest of the file, those paths appear multiple times in [LibraryPaths] section. Similar multiplicity exists in other sections i.e [PYTHONPATH] and [Paths]. So, when writing the shell script, can I omit multiplicity of paths? @pieper @lassoan

Built many times so far, but not the sweetest option on a shared cluster without administrative privileges.

I shall try the first part of your suggestion.

If you want to have a shared Slicer with extensions installed, you can also just copy all the extensions in lib\Slicer-4.11 folder. No need to modify any settings or paths.

If you don’t want to copy the files, you can just list the modules folders in the command line to start slicer.
I often have a small shell script to start up slicer with extensions under development and just point to their build directories.

I don’t have one handy, but something like:

Slicer --additional-module-paths \
  ${extdir}/cli-modules \
  ${extdir}/qt-loadable-modules \
  ${extdir}/qt-scripted-modules \

all the extensions will follow the same pattern.

1 Like

Hi @pieper, sorry I might be a little late to check on this. I tried the following:

./Slicer --additional-module-paths .config/NA-MIC/Extensions-28257/DiffusionQC/lib/Slicer-4.10/cli-modules/ .config/NA-MIC/Extensions-28257/DiffusionQC/lib/Slicer-4.10/qt-scripted-modules/ --launch bin/python-real .config/NA-MIC/Extensions-28257/DiffusionQC/lib/Slicer-4.10/cli-modules/ -h

But ran into the error:

  Slicer [options]

  --launcher-help                                 Display help
  --launcher-version                              Show launcher version information
  --launcher-verbose                              Verbose mode
  --launch                                        Specify the application to launch
  --launcher-detach                               Launcher will NOT wait for the application to finish
  --launcher-no-splash                            Hide launcher splash
  --launcher-timeout                              Specify the time in second before the launcher kills the application. -1 means no timeout (default: -1)
  --launcher-load-environment                     Specify the saved environment to load.
  --launcher-dump-environment                     Launcher will print environment variables to be set, then exit
  --launcher-show-set-environment-commands        Launcher will print commands suitable for setting the parent environment (i.e. using 'eval' in a POSIX shell), then exit
  --launcher-additional-settings                  Additional settings file to consider
  --launcher-additional-settings-exclude-groups   Comma separated list of settings groups that should NOT be overwritten by values in User and Additional settings. For example: General,Application,ExtraApplicationToLaunch
  --launcher-ignore-user-additional-settings      Ignore additional user settings
  --launcher-generate-exec-wrapper-script         Generate executable wrapper script allowing to set the environment
  --launcher-generate-template                    Generate an example of setting file
  --designer                                      Start Qt designer using Slicer plugins
Unknown option: --
usage: bin/python-real [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.

So, am I not using it the right way?

Ah, right - the problem here is that --additional-module-paths is an argument of the application, not the launcher. But I see here you are wanting to launch bin/python-real .

Probably you want something more like this, where you use the app as a python environment to it has the extensions loaded.


./Slicer-build/Slicer \
  --no-main-window \
  --python-script ${EXT_DIR}/cli-modules/ \
  --additional-module-paths \
      ${EXT_DIR}/cli-modules/ \

The suggestion ran into following error (I am connected via SSH though):

qt.qpa.screen: QXcbConnection: Could not connect to display
Could not connect to any X display.

The point of trying to run a script like above is to omit Slicer GUI.

I also tried the following (--additional-module-paths as an argument for the application now), but failed with the same error:

./Slicer --additional-module-paths ${EXT_DIR}/cli-modules/ ${EXT_DIR}/qt-scripted-modules/ --launch python-real ${EXT_DIR}/cli-modules/ -h

Unknown option: --
usage: /rfanfs/pnl-zorro/software/pnlpipe3/Slicer-4.10.2-linux-amd64/bin/../bin/./python-real [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.

Probably easiest just to install and run Xdummy. You shouldn’t need any of the GLX options if you just want to run the script.

Okay, solved the X error. Now, how would I provide argument to the python-script I want to run?

./Slicer --additional-module-paths {EXT_DIR}/cli-modules/ {EXT_DIR}/qt-scripted-modules/ --no-main-window --python-script ${EXT_DIR}/cli-modules/ -h

The above prints Slicer’s help message, not the one from the python-script.

Ah, yes, I recall there’s a bug with -h getting grabbed by the launcher, but other args should work.

Maybe you can add suggestions for your use case to this issue:

This post may answer your question:

Also not that if you don’t need to run the application (e.g., just run Python CLI modules) then you may be able to run Python scripts using PythonSlicer executable.

Hi all,

I would like to share a solution to the above problem I figured–in @jcfr’s suggestion, if I change the last line to:

AdditionalPaths=${additional_module_paths} ${launcher} --launcher-additional-settings ${slicer_revision_user_settings}

it goes away. As you can see, the trick is to move the additional paths from end to front.

For what it’s worth, I am no longer in python-real. I needed to launch a module from SlicerDMRI:

AdditionalPaths=${additional_module_paths} ${launcher} --launcher-additional-settings ${slicer_revision_user_settings} --launch .config/NA-MIC/Extensions-28257/SlicerDMRI/lib/Slicer-4.10/cli-modules/FiberTractMeasurements --help

Lastly, to echo Andras’ suggestion, I think I am better off building an independent Slicer in future.


I have a similar question to this post. I want to make a minor modification to a Slicer Extension for another lab member to use. Is the best approach to build everything in a docker and package the extension modification? something like:

as long as the group all have a similar linux environment on a local machine should be ok?

I would recommend to send a pull request to the extension’s repository. Then not only that lab member but all other users can benefit from the change.

In general, “similar” build environment is not sufficient for achieving binary compatibility, but you can try and it may or may not work. To ensure binary compatibility, you need to have the exact same build environment, which is the easiest to achieve if you build on the same computer (physical or virtual machine or container).

thank you. i’ll try both. the modification is very much a hack that breaks other functionality a user might want. I need to give it some thought how to not break existing the calculation.