# Python wrapping on the new external vtkAddon

**URL:** <https://discourse.slicer.org/t/python-wrapping-on-the-new-external-vtkaddon/10826>\
**Category:** Development\
**Created:** [March 25, 2020, 10:14am UTC](https://discourse.slicer.org/t/python-wrapping-on-the-new-external-vtkaddon/10826 "2020-03-25T10:14:15Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![RafaelPalomar](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/rafaelpalomar/32/1436_2.png) [@RafaelPalomar](https://discourse.slicer.org/u/RafaelPalomar)\
**Post date:** [March 25, 2020, 10:14am UTC](https://discourse.slicer.org/t/python-wrapping-on-the-new-external-vtkaddon/10826/1 "2020-03-25T10:14:15Z")

</div>

Hello.

I like very much the idea of having vtkAddon as a separated project as introduced in [aaf75e2aaa](https://github.com/Slicer/Slicer/commit/aaf75e2aaa70a92f16b3ea544b7a8901a98cd509). In this logic, one can think about vtkAddon being a dependency of Slicer --this helps e.g., supporting the idea of having 3D Slicer installed in a system alongside other related projects, where the common dependencies are shared.

In the current implementation, the python wrapping of vtkAddon relies on macros defined in vtkMacroKitPythonWrap.cmake (which is part of 3D Slicer), making impossible to build vtkAddon by itself and producing a cyclic dependency vtkAddon–\>Slicer–\>vtkAddon.

I would suggest to move a copy of vtkMacroKitPythonWrap.cmake to vtkAddon/CMake as a temporary solution, assuming that the integration of the official VTK will soon come, and that VTK will be the provider of the wrapping functions. Does it make sense? Any thoughts?

---

<div class="post-metadata">

**Author:** ![RafaelPalomar](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/rafaelpalomar/32/1436_2.png) [@RafaelPalomar](https://discourse.slicer.org/u/RafaelPalomar)\
**Post date:** [March 25, 2020, 11:14am UTC](https://discourse.slicer.org/t/python-wrapping-on-the-new-external-vtkaddon/10826/2 "2020-03-25T11:14:09Z")

</div>

I see that the Slicer fork of vtkAddon is much more tangled to Slicer than I thought; there are also some specific Slicer variables.

Would it make sense to make like a neutral vtkAddon with all the additions over the original by Lorensen (python wrapping, extra components)? Slicer could get the same configuration by passing cmake variables to the external project and let other projects use it.

---

<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:** [March 25, 2020, 2:42pm UTC](https://discourse.slicer.org/t/python-wrapping-on-the-new-external-vtkaddon/10826/3 "2020-03-25T14:42:32Z")

</div>

> [@RafaelPalomar](#):
>
> I would suggest to move a copy of vtkMacroKitPythonWrap.cmake to vtkAddon/CMake as a temporary solution, assuming that the integration of the official VTK will soon come, and that VTK will be the provider of the wrapping functions. Does it make sense? Any thoughts?

We will revisit the approach when transitioning to use the latest version of VTK (in the coming days), and will most likely get ride of `vtkMacroKitPythonWrap.cmake` and use the latest build-system infrastructure made available in VTK.