Thank you JC, this indeed appears to have been the case. I was using Parallels, and installed Slicer on a mounted volume. The file names were not showing up as case-insensitive in the file browser, but apparently this was the issue. After I installed Slicer in a local FS Parallels folder, things returned back to normal.
Do we have documentation anywhere saying that a case sensitive file system is suggested? Maybe we should have a small test that runs on startup and warns if a case-insensitive file system is detected.
Windows uses case-insensitive file system, topic. Why it is not a problem there (it imports pydicom)?
Both Slicer’s DICOM module and pydicom is very brave to claim such a generic word as “dicom” for its name, but especially pydicom, as a Python package, it should have chosen a more specific name. Anyway, we cannot expect pydicom to be renamed, so should we change the Slicer module name? Maybe to DICOMBrowser?
But the whole thing does seem very fragile. Isn’t there some other way to namespace these things? Like what if someone decides to name their python package slicer? (guess we should grab that one).
Good point. There are no problem on windows. See experiment below.
That said, the path containing DICOM.py is indeed listed first in sys.path
I suspect that the function listing files in a directory on a case insensitive macOS always return lower case files whereas on windows the case is maintained in the listing.
Also worth noting that ~/.local/lib/python2.7 is listed … more on that below.
import of dicom vs DICOM / macOS, Linux, Window / Installed Slicer from Sept 11 (r27399)
Windows
Here is what happen using the latest windows nightly build: