# \`import dicom\` resolves differently across platforms

**URL:** <https://discourse.slicer.org/t/import-dicom-resolves-differently-across-platforms/4072>\
**Category:** Development\
**Tags:** bug, python\
**Created:** [September 11, 2018, 4:46pm UTC](https://discourse.slicer.org/t/import-dicom-resolves-differently-across-platforms/4072 "2018-09-11T16:46:11Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [September 11, 2018, 4:46pm UTC](https://discourse.slicer.org/t/import-dicom-resolves-differently-across-platforms/4072/1 "2018-09-11T16:46:11Z")

</div>

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

mac (resolves to pydicom):

```auto
>>> 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):

```auto
>>> 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?

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [September 11, 2018, 6:05pm UTC](https://discourse.slicer.org/t/import-dicom-resolves-differently-across-platforms/4072/2 "2018-09-11T18:05:18Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [September 11, 2018, 6:32pm UTC](https://discourse.slicer.org/t/import-dicom-resolves-differently-across-platforms/4072/3 "2018-09-11T18:32:34Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [September 11, 2018, 7:23pm UTC](https://discourse.slicer.org/t/import-dicom-resolves-differently-across-platforms/4072/4 "2018-09-11T19:23:41Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [September 11, 2018, 7:48pm UTC](https://discourse.slicer.org/t/import-dicom-resolves-differently-across-platforms/4072/5 "2018-09-11T19:48:26Z")

</div>

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

Great idea

For the buildsystem, what about:

```auto
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 …

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [September 11, 2018, 7:55pm UTC](https://discourse.slicer.org/t/import-dicom-resolves-differently-across-platforms/4072/6 "2018-09-11T19:55:41Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [September 11, 2018, 9:31pm UTC](https://discourse.slicer.org/t/import-dicom-resolves-differently-across-platforms/4072/7 "2018-09-11T21:31:36Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [September 11, 2018, 9:52pm UTC](https://discourse.slicer.org/t/import-dicom-resolves-differently-across-platforms/4072/8 "2018-09-11T21:52:42Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [September 11, 2018, 10:20pm UTC](https://discourse.slicer.org/t/import-dicom-resolves-differently-across-platforms/4072/9 "2018-09-11T22:20:24Z")

</div>

> [@lassoan](#):
>
> we cannot expect pydicom to be renamed,

It was [just renamed for the 1.0 release](https://pydicom.github.io/pydicom/stable/transition_to_pydicom1.html) - 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).

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [September 11, 2018, 10:20pm UTC](https://discourse.slicer.org/t/import-dicom-resolves-differently-across-platforms/4072/10 "2018-09-11T22:20:42Z")

</div>

> [@lassoan](#):
>
> Maybe to DICOMBrowser?

That makes sense. 👍

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [September 11, 2018, 11:47pm UTC](https://discourse.slicer.org/t/import-dicom-resolves-differently-across-platforms/4072/11 "2018-09-11T23:47:06Z")

</div>

> [@lassoan](#):
>
> Windows uses case-insensitive file system, topic. Why it is not a problem there (it imports pydicom)?

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`

 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/c/a/ca96221859dbb26981ab8805e6fa1beadde45efd.png)

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:

 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/7/d/7da425ac94f5033bcdc893b230671a54633506a7.png)

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:

```auto
>>> 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

 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/7/1/716f40e06be509d57dda9498c34d096488ad98e9.png)

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.

 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/c/a/ca96221859dbb26981ab8805e6fa1beadde45efd.png)

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [September 12, 2018, 12:41pm UTC](https://discourse.slicer.org/t/import-dicom-resolves-differently-across-platforms/4072/12 "2018-09-12T12:41:50Z")

</div>

> [@jcfr](#):
>
> Not sure what is happening … it may be worth doing more experiment in that setup.

Does that mac have a case-sensitive filesystem?