I am adding a new module directory via application settings, but after restart, the added directory disappears. There are no errors relevant to this during application startup. I observe this with both 5.10 and nightly. I am on a mac. I tried this with an empty directory, and the behavior is the same, so it is not related to the specific module.
Additional module paths are checked at application startup and if the folder does not exist then it is removed. Could you have a look at the Slicer-NNN.ini file and see what paths are listed there, how they are defined (with relative path?) and if they can be found on your system? Are the folders on a physical disk or some virtual/network drive?
It is not very useful but I want to add that I have seen this, and couple other variants, such as drag and dropping a module folder onto the Slicer windows not bringing the “add these python scripts to module paths” option, or extension wizard not recognizing some module folders, sporadically on MacOS. Never managed to consistently replicate though.
The folder definitely exists. I created the folder, and selected that folder from the file picker. I confirm the folder itself remains in place after Slicer restart.
When I look at the ~/.config/slicer.org/Slicer.ini file, I do not see the added folder anywhere before or after the restart. Is this the right file to check?
Physical drive, main drive on a mac mini.
I do not see this issue on linux.
The Slicer-NNN.ini file is the revision-specific config file in the application’s install path. You can get the path by typing this into the Slicer Python console:
slicer.app.slicerRevisionUserSettingsFilePath
If the path is not added to this .ini file then there may be some macOS permission issues. @pieper have you experienced something like this lately?
1 Like
I don’t usually use the settings files for this. I use the --additional-module-paths command line argument (this helps isolate different experiments using the same Slicer version).
I checked, and this is the file:
ls -lat /Applications/Slicer-20251129.app/Contents/bin/../slicer.org/Slicer-34291.ini
-rw-r–r–@ 1 rsna2023 admin 1686 Dec 1 15:37 /Applications/Slicer-20251129.app/Contents/bin/../slicer.org/Slicer-34291.ini
To add more detail, on this system I installed Slicer under a different account, and then have been using it under the rsna2023 user account. I confirmed rsna2023 user can write to this file, but the file is unchanged before or after the restart if I try to remove a path in the Application module settings.
To me, the unresolved questions are:
- Why is that file remaining unchanged?
- The way permissions are set up for that file, since application is shared across users on the system, it will definitely be problematic, since it is readable only by one user. Is this a bug?
- There does not seem to be any error at any point that would indicate failure to modify that settings file. Is this a bug?
Here’s the full contents of the file.
[Extensions]
[Extensions]
FrontendServerUrl=https://extensions.slicer.org
InstallPath=Extensions-34291
LastServerAPI=Girder_v1
ManagerEnabled=true
MetadataFromServerUpdateTime=2025-12-01T02:52:59Z
MetadataFromServerUrl=https://slicer-packages.kitware.com
ServerUrl=https://slicer-packages.kitware.com
[LibraryPaths]
1\path=Extensions-34291/QuantitativeReporting/lib/Slicer-5.11
2\path=Extensions-34291/SlicerDevelopmentToolbox/lib/Slicer-5.11
3\path=Extensions-34291/IDCBrowser/lib/Slicer-5.11
4\path=Extensions-34291/DCMQI/lib/Slicer-5.11
5\path=Extensions-34291/DCMQI/lib/Slicer-5.11/cli-modules
6\path=Extensions-34291/PETDICOMExtension/lib/Slicer-5.11
7\path=Extensions-34291/PETDICOMExtension/lib/Slicer-5.11/cli-modules
size=7
[Modules]
AdditionalPaths=Extensions-34291/QuantitativeReporting/lib/Slicer-5.11/qt-scripted-modules, Extensions-34291/SlicerDevelopmentToolbox/lib/Slicer-5.11/qt-scripted-modules, Extensions-34291/DCMQI/lib/Slicer-5.11/cli-modules, Extensions-34291/PETDICOMExtension/lib/Slicer-5.11/cli-modules, Extensions-34291/PETDICOMExtension/lib/Slicer-5.11/qt-scripted-modules
IgnoreModules=@Invalid()
[PYTHONPATH]
1\path=Extensions-34291/QuantitativeReporting/lib/Slicer-5.11/qt-scripted-modules
2\path=Extensions-34291/SlicerDevelopmentToolbox/lib/Slicer-5.11/qt-scripted-modules
3\path=Extensions-34291/IDCBrowser/lib/Slicer-5.11/qt-scripted-modules
4\path=Extensions-34291/PETDICOMExtension/lib/Slicer-5.11/qt-scripted-modules
size=4
[Paths]
1\path=Extensions-34291/DCMQI/lib/Slicer-5.11/cli-modules
2\path=Extensions-34291/PETDICOMExtension/lib/Slicer-5.11/cli-modules
size=2
[QT_PLUGIN_PATH]
size=0
I’m not sure how much this behavior is expected in a multi-user environment, but not giving the user any feedback when the .ini file update is failed is definitely a bug that should be fixed. I’ve created an issue for it:
@fedorov Could @Sunderlandkyl work on this as part of his IDC activities?
Only if this is a trivial fix. There are IDC tasks outside of Slicer development that I need to get Kyle to start working on, once the already assigned Slicer tasks are completed.
OK, makes sense, thank you for the clarification.
Until today, I always installed Slicer into the Applications folder on Mac. I moved the app into one of my user folders, and now everything works as expected.
I think the conclusion is that if there is any chance Slicer can be used in a multi-user setting, it should not be installed into the Applications folder on Mac.
We could change the dmg file to include a link to the user’s local Applications folder rather than the system one.