Python wrapping (some elements missing)

Support
1

Hello,

I’m playing with building slicer with SLICER_SUPERBUILD=OFF and trying to get a modular and installable version of slicer in linux. So far, I managed to build the dependencies from the superbuild, 3D Slicer libs, 3D slicer app (without Slicer Launcher) including CLI and Python support. I build also the Slicer modules separately (not all-in or all-out as one would normally would)

Though I see all the *Python.so and the *PythonD.so files are generated (both for Slicer libraries and for the modules), I cannot access some MRML nodes (e.g., slicer.vtkMRMLSegmentEditorNode does not exist). However other nodes like slicer.vtkMRMLAbstractViewNode are avalable. It seems to me that the Slicer-Libs are wrapped and available properly but not the loadable modules.

I know this is a weird setup and very specific, but if anyone has any intuition on what should I be looking for or what could I test to find the problem, please let me know.

Best,
Rafael.

2

Maybe just to narrow down the question. What is the mechanism by which MRML nodes are added to the slicer python namespace? This would probably help me find the problem.

Thanks!

3

Digging a little bit more…I see that

import vtkSlicerSegmentationsModuleMRMLPython

works. Then trying

vtkSlicerSegmentationsModuleMRMLPython.vtkMRMLSegmentEditorNode()

fails

Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: this class cannot be instantiated
4

Hi @RafaelPalomar -

This sounds like an interesting project - is your goal to be able to use standard vtk/itk/python linux packages to build Slicer? This could be really helpful, but just FYI, we’ve been down this path before (it might still be possible to apt-get install Slicer version 3 on debian) but run into a lot of problems getting bug fixes and other updates into upstream packages. Since all the code is under coninuous development, the Slicer build process requires we be able to build and distribute our own versions of dependencies in some cases.

That said, it sounds like you are on the right path. Be sure all the libraries are in the python path, and also be careful about the order of importing. As I recall if you don’t import in the correct sequence not all the subclass methods are instantiated for a class (you might strace the Slicer launcher process to see what all is being read in and in what sequence).

5

Hello @pieper,

thank you for the reply. Yes, that’s the main idea. I see that Slicer has the basic infrastructure to achieve this, is just that it has not been developed any further for very long time. Particularly, all the CMake plumbing related to the install tree.

I’ve been digging a little more and found that the vtkSlicerSegmentationsModuleMRML_WRAP_DEPENDS variable when I build the loadable modules separately lacks the following dependencies compared to the standard superbuild Slicer: vtkAddon;vtkSegmentationCore;vtkTeem;vtkITK;FreeSurfer;MRMLCore;MRMLLogic;MRMLDisplayableManager;MRMLCLI;vtkSlicerSubjectHierarchyModuleLogic;SlicerBaseLogic;qSlicerBaseQTCLI which I would think are needed to complete the implementation (parent classes). This might explain the error when trying to instantiate the MRML nodes and maybe (silently) causes the no inclusion in the slicer python namespace.

This is the last bit I need to get a workable version of Slicer integrated in the OS, so I hope I can solve it and we can discuss further on the next NA-MIC Week :slight_smile:

6

Excellent idea! :+1:

7

Hello,

for reference, if anyone experience similar issues, the problem is related to what I exposed in my last post. Slicer does not install any xxxHierarchy.txt file these are needed in the install tree; in addition, the mapping of Slicer_WRAP_HIERARCHY_FILES_CONFIG variable with the right install paths is needed for the SlicerConfig.cmake file for the install tree.

The solution for me was to modify the vtkMacroKitPythonWrap.cmake to install the generated hierarchy files, modify SlicerGenerateSlicerConfig.cmake to record the install path of the hierarchy files and register them in SlicerInstallConfig.cmake.in.
(https://github.com/RafaelPalomar/Slicer/tree/systole-patches/Slicer).

@pieper, @lassoan, @jcfr Based on the experience of this post, I think that a MRMLNode B, inheriting from a MRMLNode A which belongs to an external module, will not be wrapped in Python. For this to work in a build tree, a “ModuleConfig.cmake” file would be needed (I don’t think it exists now?). For an install tree I would advocate for a creation of a drop-in directory in the install tree where all the modules drop a configuration file exposing all the needed variables. Does this make any sense?

8

Sounds good to me (but I haven’t looked at these things in a long time and I don’t know what current practices are on the VTK side.)

9

I would recommend to first help with migrating Slicer to VTK-8.90 (VTK-9 preview) as Python wrapping is changed completely. For example, hierarchy files are not used anymore.

@cpinter how far did you get with updating Slicer to VTK-8.90?

10

I haven’t had the chance to work on this since our last conversations

I think we are very close, just a few more issues to address.

1 Like
11

@cpinter is there an update on this effort. I am not sure what I am looking at when I follow that link provided.

12

The link above is redirected to an unrelated issue. The original pull request belongs to the old repository, which has been renamed to SlicerGitSVNArchive, that’s why.

As far as I know @jcfr got some funding for the VTK update work, and probably will get to it as soon as he has capacity. This is the issue where you can follow the events and related commits: https://github.com/Slicer/Slicer/issues/4696