Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slicer fails to load SegmentEditorExtraEffects from SilceTracker #37

Closed
tokjun opened this issue Oct 8, 2020 · 6 comments
Closed

Slicer fails to load SegmentEditorExtraEffects from SilceTracker #37

tokjun opened this issue Oct 8, 2020 · 6 comments

Comments

@tokjun
Copy link

tokjun commented Oct 8, 2020

While invistigating the SliceTracker issue on the new Slicer release( https://discourse.slicer.org/t/slicetracker-module-cannot-be-loaded-on-slicer-4-11-20200930/13895/3 ), I found that Slicer fails to load SegmentEditorExtraEffects from SilceTracker:

SyntaxError: invalid syntax
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/junichi/slicer/Slicer-4.11.20200930-linux-amd64/lib/Python/lib/python3.6/imp.py", line 170, in load_source
    module = _exec(spec, sys.modules[name])
  File "<frozen importlib._bootstrap>", line 618, in _exec
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/home/junichi/.config/NA-MIC/Extensions-29402/SliceTracker/lib/Slicer-4.11/qt-scripted-modules/SurfaceCutToLabel.py", line 11, in <module>
    from SegmentEditorSurfaceCutLib import SurfaceCutLogic
  File "/home/junichi/.config/NA-MIC/Extensions-29402/SegmentEditorExtraEffects/lib/Slicer-4.11/qt-scripted-modules/SegmentEditorSurfaceCutLib/__init__.py", line 4, in <module>
    from SegmentEditorEffect import *
ModuleNotFoundError: No module named 'SegmentEditorEffect'
TypeError: module.__init__() argument 1 must be str, not qSlicerScriptedLoadableModule
tokjun added a commit to tokjun/SlicerSegmentEditorExtraEffects that referenced this issue Oct 8, 2020
@lassoan
Copy link
Owner

lassoan commented Oct 9, 2020

I cannot reproduce the error using Slicer 4.11.20200930 (revision 29402 / 002be18) linux-amd64 - installed release.

If I type this into the Python console then I don't get any error:

from SegmentEditorSurfaceCutLib import SurfaceCutLogic

What did you do when this error showed up for you?

@tokjun
Copy link
Author

tokjun commented Oct 9, 2020

Thanks for trying. I simply downloaded the release, installed SliceTracker and all necessary extensions from the Extensions Manager, and restarted. There were other messages before the quoted message. See my posting on the Slicer Discourse.

@lassoan
Copy link
Owner

lassoan commented Oct 9, 2020

I was able to reproduce the problem and it was caused by having from SegmentEditorSurfaceCutLib import SurfaceCutLogic in the global namespace of SurfaceCutToLabel.py. Since at the time of loading a Python module, other modules may not be loaded and initialized yet, it leads to errors if other modules are attempted to be used in any way.

So, instead of changing the import strategy in all segment editor effects (in this extension and several others), a less intrusive and more robust solution is to move from SegmentEditorSurfaceCutLib import SurfaceCutLogic into SurfaceCutToLabelLogic._initializeSurfaceCutLogic.

@tokjun
Copy link
Author

tokjun commented Oct 9, 2020

Thanks for the suggestion. I like the less invasive way you suggested.

By the way, the change I proposed was actually coming from one of the templates for slicerExtensionWizard:

https://github.com/Slicer/Slicer/blob/master/Utilities/Templates/Modules/ScriptedSegmentEditorEffect/SegmentEditorTemplateKeyLib/__init__.py

While working on the issue, I realized that the code was originally generated by the wizard, and the current version of the ScriptedSegmentEditorEffect does absolute import. So I thought it would make sense to change the import strategy in this extension.

@lassoan
Copy link
Owner

lassoan commented Oct 9, 2020

I agree, explicit relative import is probably the right thing to do, but I would rather do it when we must change something around these imports anyway (I would like to avoid spending time now with testing potential side effects of this change).

@tokjun
Copy link
Author

tokjun commented Oct 9, 2020

Sounds good. Thank you!

@tokjun tokjun closed this as completed Oct 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants