Installing extensions in binary distribution of Slicer

Support
2

Assuming the user where Slicer and the extensions are installed is called slicer, the idea is to create a script called SlicerWithExtensions.sh 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
launcher=${script_dir}/Slicer
launcher_settings=${script_dir}/bin/SlicerLauncherSettings.ini
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
fi
if [ ! -f ${launcher_settings} ]; then
  echo "${script_name} is expected to exist along side the Slicer launcher: ${launcher_settings} not found"
  exit 1
fi

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

# revision user settings
slicer_revision_user_settings=/home/${slicer_user}/.config/NA-MIC/Slicer-${revision}.ini
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
fi

# 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)

[...]

[Application]
path=<APPLAUNCHER_DIR>/bin/SlicerApp-real
arguments=
name=Slicer
revision=27931
organizationDomain=www.na-mic.org
organizationName=NA-MIC

[...]

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