Installing extensions in binary distribution of Slicer

I need to install a few extensions like SlicerDMRI and make it available for everyone at my office.

On Partner’s cluster environment, compiling Slicer from source code with desirable .s4ext files, isn’t the best option.

So, I have to resort to ExtensionManager on the Slicer GUI. I installed my desired extensions. The modules are discoverable when I launch Slicer. However, they are not discoverable to other users automatically. Interestingly, when I use a different workstation, they are not discovered either.

I have tried ./Slicer --additional-module-paths path1 path2 ..., but I ran into errors that stem from incomplete PYTHONPATH and LD_LIBRARY_PATH.

The question is, what is the most manageable way to install extensions and make it available for all users using that Slicer?

Assuming the user where Slicer and the extensions are installed is called slicer, the idea is to create a script called along side the Slicer launcher in your shared installation.

The script only need to be updated with the name of the user under which Slicer is installed on the cluster:

#!/bin/bash -e

# This is the username associated with the Slicer installation to share between users.
slicer_user=jcfr # TODO: Update this line

script_dir=$(cd $(dirname $0) || exit 1; pwd)
script_name=$(basename $0)

# launcher and launcher settings
echo "Launcher settings ........: ${launcher_settings}"

# sanity checks
if [ ! -f ${launcher} ]; then
  echo "${script_name} is expected to exist along side the Slicer launcher: ${launcher} not found"
  exit 1
if [ ! -f ${launcher_settings} ]; then
  echo "${script_name} is expected to exist along side the Slicer launcher: ${launcher_settings} not found"
  exit 1

# extract revision
revision=$(cat  ${launcher_settings} | grep revision= | cut -d= -f2)
echo "Revision .................: ${revision}"

# revision user settings
echo "Revision user settings ...: ${launcher_settings}"

# sanity check
if [ ! -f ${slicer_revision_user_settings} ]; then
  echo "Slicer revision user settings not found: ${slicer_revision_user_settings}"
  exit 1

# extract additional module paths
# TODO Handle module path with spaces
additional_module_paths=$(cat  ${slicer_revision_user_settings} | grep AdditionalPaths= | cut -d= -f2 | tr -d ",")
echo "Additional module paths ..: ${additional_module_paths}"

${launcher} --launcher-additional-settings ${slicer_revision_user_settings} --additional-module-paths ${additional_module_paths} "$@"

more details

Generally speaking, extensions are installed in the Slicer setting directory specific to the user and all information are added to a ini file. For example, the ini file associated Slicer 4.10.1 on linux is ~/.config/NA-MIC/Slicer-27931.ini.

After installing an extension, you can see settings groups like [LibraryPaths], [PYTHONPATH], [Paths] and also [Modules] with the key AdditionalPaths.

To automatically set the environment before starting the real Slicer application, the Slicer launcher is able to infer the path to the user Slicer revision specific file ~/.config/NA-MIC/Slicer-27931.ini given information found in the launcher settings.

Here is a snippet of the launcher settings associated with Slicer 4.10.1 (e.g. /path/to/Slicer-4.10.1-linux-amd64/bin/SlicerLauncherSettings.ini)




Within the [Application] group, we can see the key name, revision and organizationName. These information are sufficient to retrieve the revision specific settings file and compose the environment needed to load the additional modules associated with the AdditionalPaths key.

1 Like

You mean called jcfr ?

You mean called jcfr ?

Assuming the user where Slicer and the extensions are installed is called slicer

Indeed, I edited the post to be more clear. Let us know how it works out.

For a week, the environment was down. After it came back online, I tried your instruction. It is mostly correct, except another user would not have access to a file in my home directory:


To get around that, I have done the following:

When you install an extension using the Extension Manager, it allows you to specify a path other than the default /home/${slicer_user}/.config/NA-MIC/Slicer-${revision}.ini directory. I have put in a shared path. The Extension got installed, and the above .ini file got written as it should be. Then, I just copied over the .ini file from my home directory to the shared path.

Rest assured, now I have a way to make Extensions available to all other users that I installed.

1 Like


{launcher} --launcher-additional-settings {slicer_revision_user_settings} --additional-module-paths {additional_module_paths} "@"

The “$@” is failing here. For example, I have tried the following command with additional arguments, but it fails:

Slicer-4.10.2-linux-amd64/ --launch python-real SlicerDiffusionQC/Test/

Error message:

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.

I understand you are trying to get any additional argument passed to the script.

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