"slicerizer" app to install and manage Slicer application versions

[pieper]

Is your feature request related to a problem? Please describe.

As discussed in a recent dev meeting, a utility to manage downloads could be useful. The current methods to install Slicer binaries require multiple user-actions and vary across platforms. There is a lot of repetitive effort required, for example, to compare the behavior of an extension in, say, the stable and preview versions of Slicer on multiple platforms.

Here's a common current workflow on a fresh VM:

• install a browser
• go to download.slicer.org and click the correct button for your os / version choice
• open downloaded archive, (windows: run installer)
• launch slicer, go to extensions manager, seach and install each extension
• restart slicer
• repeat for each platform you want to test

Describe the solution you'd like

A simple command that would download and install Slicer consistently across platforms.

Inspired by this package that installs platform-specific executables via PyPi, we could leverage pypi to distribute a program that performs the installation and manages executable paths.

Here's are some sample uses for bash (the exact command name is open for discussion).

Install Slicerizer

pip install slicerizer

install and run the latest stable

slicerizer install
Slicer

install and run the latest preview

preview=$(slicerizer install --preview)
${preview}

install and run a specific version with extensions installed

slicer561=$(slicerizer install --version 5.6.1 --extensions SlicerDMRI,SlicerRT)
${slicer561}

query the installed Slicer versions and their extensions

slicerizer query --format json
[
  {"Version": "5.6.1",
   "InstallData": "2024-03-21",
   "Extensions": ["SlicerMorph", "MONAILabel"],
   "ExecPath": "/Users/pieper/app/Slicer-5.6.1.app/Contents/MacOS/Slicer"
  }
]

Describe alternatives you've considered

We don't need to use pypi, but it seems convenient. Instead we could provide a shell script for linux/mac and a .bat or powershell script for windows, but maintaining multiple versions would be a hassle.

Also this feature could be included in Slicer itself, so that once you've installed one version it helps you manage your isntallations of other versions. But that wouldn't for installing a Slicer version on fresh VMs.

Depending on user feedback, we might also consider adding a GUI to select which Slicer to launch.

There are also lots of potentially useful command line options to consider adding:

• a command to update the preview or release if one is available
• an option to auto-launch when download and installation are complete'
• an option for windows to automate running the installer
• options to specify the installation directory
• options to save or not save the installer archive
• options to delete older versions
• options to query and list versions available for installation, and what extensions are available for them

Other name ideas:

• SlicerBuddy
• SlicerConfigurationManager
• slicer-apputil
• slicertool
• slicervalet

Additional context

Use cases:

• Easy cross-platform cut-and-paste command to install a specific version of slicer
  • for recreating a debugging scenario
  • for quickly testing a feature of a preview build on multiple machines
  • for getting access to an older version where an extension is known to work
  • for using a specific version as part of an ongoing experiment
• A graphical interface to pick among installed versions
• An easy way to get the latest preview with bookmarked extensions auto-installed
• A way for batch processing scripts to specify the required slicer and extensions without user interaction

[lassoan]

This would be great. It could also be used to easily run Slicer in Python-based environments such as Google colab. It could even have a utility function to set up a novnc server.

I like the slicertool name much better than slicerizer (slicerizer would be good for something like running a Python script within Slicer environment; or turning a Python script into a Slicer module, ...). It would also reflect that it may contain other Slicer-related utilities.

Since this installer would need to work hand-in-hand with slicerio (for example, slicerio should be able to automatically find the Slicer installed by slicertool), we could also consider just adding slicer installation functionality to slicerio. We would then not need to create and maintain a separate Python package. I have no problem moving slicerio to the Slicer github organization and adding any Slicer core developers to the maintainers on PyPI.

[pieper]

Yes, it could make sense to have both functionalities under one umbrella. For example both could expose a cli and a python API for the same features so they could easily be used together.

Especially for slicerio, it would be nice to be able to have a command option to start Slicer with the WebServer enabled.

Moving slicerio to the Slicer org and unifying our pypi presence also makes sense.

[jcfr]

Cc: @allemangD

[jcfr]

Thanks @pieper for creating the issue 🙏

[lassoan]

Especially for slicerio, it would be nice to be able to have a command option to start Slicer with the WebServer enabled.

slicerio.server can do exactly this (automatically launches Slicer with the web server enabled, if a server is not already running), it just requires an already installed Slicer and its location has to be specified in an environment variable or as a method argument.

Moving slicerio to the Slicer org and unifying our pypi presence also makes sense.

Sounds good! Since it takes some effort to update all the URLs, etc. I'll do this change when we create the new slicerio release with the new features. So, the first PR should go to the existing repository location.