`import dicom` resolves differently across platforms

bug
python

(Andrey Fedorov) #1

It appears that import dicom works inconsistently across platforms, perhaps this is due to runtime load ordering issues:

mac (resolves to pydicom):

>>> import dicom
>>> print dicom
<module 'dicom' from '/Applications/Slicer.app/Contents/lib/Python/lib/python2.7/
  site-packages/dicom/__init__.pyc'>

linux (resolves to Slicer DICOM module):

>>> import dicom
>>> print dicom
<module 'dicom' from '/media/psf/Home/Slicer-4.9.0-2018-09-10-linux-amd64/lib/

Anyone has a workaround for this problem?


(Jean Christophe Fillion Robin) #2

I suspect this happens on case-insensitive filesystem.

If this is the case:

  • switch to case sensistive filesystem
    or
  • rename faulty module to have different name

(Andrey Fedorov) #3

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.


(Steve Pieper) #4

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.


(Jean Christophe Fillion Robin) #5

a small test that runs on startup and warns if a case-insensitive file system is detected.

Great idea

For the buildsystem, what about:

file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/TestCaseSensitiveFileSystem.txt" "1")
file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/Testcasesensitivefilesystem.txt" "0")
file(READ "${CMAKE_CURRENT_BINARY_DIR}/TestCaseSensitiveFileSystem.txt" is_case_sensitive_filesystem)
if(NOT is_case_sensitive_filesystem)
  message(FATAL_ERROR "")
endif()

and for the runtime, we could do similar test in C++ or python. Or use an existing system call …


(Jean Christophe Fillion Robin) #6

And to clarify, I would be happy to review a pull-request if someone want to implement such configure and/or runtime test


(Jean Christophe Fillion Robin) #7

For reference, here is the corresponding Slicer issue: https://issues.slicer.org/view.php?id=4606


(Andras Lasso) #8

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?


(Steve Pieper) #9

It was just renamed for the 1.0 release - dicom now it’s pydicom.

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


(Jean Christophe Fillion Robin) #10

That makes sense. :+1:


(Jean Christophe Fillion Robin) #11

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:

The two paths are:

  • lib/Python/Lib/site-packages/dicom (which contains __init__.py)
  • lib/Slicer-4.9/qt-scripted-modules (which contains DICOM.py)

Linux

On linux, using the latest nightly, we have:

>>> import dicom
>>> dicom.__file__
'/home/jcfr/Downloads/Slicer-4.9.0-2018-09-10-linux-amd64/lib/Python/lib/python2.7/site-packages/dicom/__init__.pyc'
>>> import DICOM
>>> DICOM.__file__
'/home/jcfr/Downloads/Slicer-4.9.0-2018-09-10-linux-amd64/bin/../lib/Slicer-4.9/qt-scripted-modules/DICOM.pyc'

The two paths are also:

  • lib/Python/lib/python2.7/site-packages/dicom
  • lib/Slicer-4.9/qt-scripted-modules

macOS

The two paths are also:

  • lib/Python/lib/python2.7/site-packages/dicom
  • lib/Slicer-4.9/qt-scripted-modules

Not sure what is happening … it may be worth doing more experiment in that setup.

PYTHONNOUSERSITE seems to be ignored on macOS

While looking at the issue, I printed the sys.path and we can see that the one containing DICOM is first.


(Steve Pieper) #12

Does that mac have a case-sensitive filesystem?