NA-MIC Project Weeks

Back to Projects List

Python dependencies in extensions

Key Investigators

• Ebrahim Ebrahim (Kitware, USA)
• Steve Pieper (Isomics, USA)
• Sam Horvath (Kitware, USA)

Project Description

Many Slicer extension developers have to deal with the problem of external python dependencies: how to specify them, how and when to install them, and how to validate that the required things are installed. Everyone addresses the problem in a different way, often re-inventing the wheel and also often generating new great ideas. I’d like to collect all the best practices and turn them into a framework that is built into core slicer for extension developers to more easily grab and use. Something like “stick your dependencies in here and the use slicer.util.check_python_dependences and slicer.util.install_python_dependencies. If that turns out to be a bad idea for whatever reason, at least I can collect all the best practices and put them into the extension development documentation.

Objective

• Encode into Slicer some way to make it more convenient for extension developers to handle external python dependencies.

Approach and Plan

• Gather best practices on external python dependency handling in Slicer extensions, and then distill them into an optimized approach.
• Encode that approach in Slicer somehow, either as utility functions, updates to extension templates, or simply documentation.

Progress and Next Steps

Table of existing practices

2026-01-26

I’ve broken down the problem of external Python dependency into three components:

• Checking: How do we check whether the dependency requirements are already met by the environment?
• Triggering: What causes the requirement installation process to start?
• Installing: How do we carry out requirement installation?

The table below includes all 94 extensions that are currently in the Slicer extension index and that have some external python dependencies to deal with, and my best quick guess as to how they approach each of the problems above. Here is a legend to interpret the terms I’ve put in the table:

• Checking:
  • simple: Checkng is done by trying to import and and catching if it fails. It could also be done with importlib. No version checking.
  • version: Does some kind of version checking as well.
• Triggering:
  • user: Nothing triggers an automatic install. The user will have to install by following some steps.
  • top level: The install is triggered at some top level like the module enter function, such that it would happen the first time the module is even switched to for example. It could also be at the truly top-level– in this case it would be triggered during module discovery, which is undesirable.
  • processing: When the user goes to run some kind of processing in the extension, that’s when it actually checks if it has the dependencies it needs and kicks off install if not.
  • button: User has to press a button to install.
• Installing:
  • user: User has to do it by following some steps.
  • simple: Just slicer.util.pip_install.
  • isolated: There is a separate environment (such as a virtual env) into which the dependencies are installed (and so it is not going to be slicer’s pip_install but some script or shell process that carries out installation).
  • blocking-prevention: Attempts to stop the installation from fully blocking the application. This could be by using threading of some sort or spawning a background process, or by otherwise trying to give slicer a chance to process events while the install is happening.
  • display: Has some more sophisticated display of what’s going on while pip installing

---

Extension	Checking	Triggering	Installing
ShapeVariationAnalyzer	simple	user	isolated
SlicerVolBrain	simple	user	user
PerkTutor	simple	top level	simple
Q3DCExtension	simple	top level	simple
QuantitativeReporting	simple	top level	simple
SegmentationReview	simple	top level	simple
Slicer-ABLTemporalBoneSegmentation	simple	top level	simple
Slicer-ASLtoolkit	simple	top level	simple
Slicer-MusculoskeletalAnalysis	simple	processing	simple
Slicer-PET-MUST-segmenter	simple	top level	simple
Slicer-TITAN	simple	processing	simple
SlicerANTsPy	simple	top level	simple
SlicerAnatomyCarve	simple	top level	simple
SlicerArduinoController	simple	top level	simple
SlicerAuto3dgm	simple	top level	simple
SlicerAutomatedDentalTools	version	processing	simple
SlicerAutoscoperM	simple	processing	simple
SlicerBigImage	simple	processing	simple
SlicerBiomech	simple	processing	simple
SlicerBreastUltrasoundAnalysis	simple	top level	simple
SlicerBreast_DCEMRI_FTV	simple	top level	simple
SlicerCADSWholeBodyCTSeg	simple	processing	simple
SlicerCBCTToothSegmentation	simple	processing	simple
SlicerCineTrack	simple	processing	simple
SlicerColoc-Z-Stats	simple	processing	simple
SlicerConnectToSupervisely	simple	processing	simple
SlicerDBSCoalignment	simple	processing	simple
SlicerDICOMwebBrowser	simple	top level	simple
SlicerDMRI	simple	processing	simple
SlicerDebuggingTools	simple	processing	simple
SlicerDensityLungSegmentation	simple	processing	simple
SlicerDentalModelSeg	version	processing	isolated, blocking-prevention
SlicerFreeSurfer	simple	top level	simple
SlicerHDBrainExtraction	simple	processing	simple
SlicerHeadCTDeid	simple	processing	simple
SlicerHeart	simple	processing	simple
SlicerIDCBrowser	simple	top level	display
SlicerIVIMFit	simple	processing	simple
SlicerImageAugmenter	simple	button	simple
SlicerJupyter	simple	processing	simple
SlicerKonfAI	version	top level	blocking-prevention
SlicerLungCTAnalyzer	simple	processing	simple
SlicerMEMOS	simple	processing	simple
SlicerMHubRunner	simple	top level	simple
SlicerMONAIAuto3DSeg	version	processing	blocking-prevention
SlicerMONAIViz	simple	processing	simple
SlicerMOOSE	simple	button	simple
SlicerMassVision	simple	top level	simple
SlicerModalityConverter	simple	button	simple
SlicerMorph	simple	top level	simple
SlicerMorphoDepot	simple	top level	simple
SlicerMultiverSeg	simple	processing	simple
SlicerMuscleMap	simple	processing	simple
SlicerNNInteractive	simple	top level	display, blocking-prevention
SlicerNNUnet	version	processing	simple
SlicerNetstim	simple	processing	simple
SlicerNeuro	simple	processing	display
SlicerNeuroStrip	simple	top level	simple
SlicerNeuropacs	version	processing	simple
SlicerOpenLIFU	simple	processing	display
SlicerOrbitSurgerySim	simple	top level	display
SlicerPhotogrammetry	simple	top level	simple
SlicerPipelines	simple	top level	simple
SlicerPolycysticKidneySeg	simple	button	simple
SlicerPyTorch	simple	button	simple
SlicerPythonTestRunner	simple	processing	simple
SlicerRVXLiverSegmentation	simple	top level	simple
SlicerRadiomics	simple	top level	simple
SlicerSPECTRecon	version	top level	display
SlicerSandbox	simple	processing	simple
SlicerSegmentHumanBody	simple	top level	simple
SlicerSegmentWithSAM	simple	top level	simple
SlicerSkeletalRepresentation	simple	top level	simple
SlicerSoundControl	simple	top level	simple
SlicerStereotaxia	simple	processing	simple
SlicerSurfaceLearner	simple	top level	simple
SlicerThemes	simple	button	simple
SlicerTissueSegmentation	simple	top level	simple
SlicerTomoSAM	simple	processing	simple
SlicerTorchIO	simple	processing	simple
SlicerTotalSegmentator	simple	processing	simple
SlicerTractParcellation	simple	button	simple
SlicerTrame	simple	top level	simple
SlicerUltrasound	simple	top level	simple
SlicerUniGradICON	simple	top level	simple
Slicerflywheelcaseiterator	simple	top level	simple
TCIABrowser	simple	top level	simple
TOMAAT-Slicer	simple	top level	simple
aigt	simple	top level	simple
opendose3d	simple	top level	display
slicer_flywheel_connect	simple	top level	simple

Next steps

2026-01-26

In the table above, the green cells are the items I think are worth revisiting and learning from for this project.

Other things I found while looking through these that I’d like to consider:

• Using slicer.util.restart to restart after install
• Showing a status message: slicer.util.showStatusMessage
• Showing the python console: slicer.util.displayPythonShell
• Using slicer.util.tryWithErrorDisplay
• Using a BusyCursor context manager

Further points that I’d like to follow up on:

• I found some thoughts from JC that I’d like to look over carefully.
• On that note, besides checking, triggering, and installing, I think there is also the problem of how to specify dependencies.
• What about the problem of conflicts between requirements of different extensions? For an example see the mess that was caused by the conflict between the total segmentator and NNUnet extensions.
• When extension unit tests are running, they have the ability to influence each other’s slicer python environment. It would be nice if there were some way to revert the slicer python environment before each extension test begins. This is out of the scope of the present project but we can consider how it might be done.

Illustrations

No response

Background and References

• The SlicerOpenLIFU extension is where I have most recently applied what I know about handling python dependencies. But it could be so much better.