<div dir="ltr"><div>Hi Ben,<br></div><div><br></div><div>Here is an updated version of the comment I originally posted on <a href="https://gitlab.kitware.com/vtk/vtk/merge_requests/3674#note_355306">MR 3674</a>.<br></div><div><br></div><div><br></div><div>Short version:</div><div><br></div><div>Having the dependency graph of VTK kits available in python is needed to generate cross platform distributable wheels.<br></div><div><br></div><div><br></div><div>Long version:<br></div><div><br>The introduction vtkmodules enables granular import.<br><br>In a install or build tree where the PATH, LD_LIBRARY_PATH, ... are set or if RPATH is available, importing any specific module will work because the dynamic library loader will find the correct dependencies and load them. (e.g ParaView, Slicer, ...)<br><br>To support generation of distributable python wheels and avoid user to compile VTK each time they want to use it, a given compiled python module can NOT depends on shared libraries and expect the library loader to find them unless:<br><br>* the dependent libraries are system ones<br>* the compiled python module explicitly loads them in order<br><br><br>What does this mean ?<br><br>* We need to support building any given kit as standalone kit without any dependencies beside of system libraries and symbols from other kit<br>* We need to make sure dependent kit are explicitly imported within python in the right order<br><br><br>Hence the need to have the dependency graph available from python.<br><br>There is also other challenges like:<br><br>* sharing symbol across python modules (e.g GlobalTimeStamp need to be the same for all modules). To address this, we use Python Capsule C/API in ITK.<br><br><br>For these reasons, we need to have the dependency graph available.</div><div><br></div><div>And once, we have the dependency graph ... supporting lazy loading wouldn't be too much work.<br></div><div><br></div><div><br>In the future, support for Native libraries in wheels would alleviate some of these issues. In the mean time, it is a necessary evil:<br><br>* <a href="https://github.com/jcfr/wheel-builders/blob/058287254a139908578501eb70b602e33202720a/pynativelib-proposal.rst">https://github.com/jcfr/wheel-builders/blob/058287254a139908578501eb70b602e33202720a/pynativelib-proposal.rst</a><br>* <a href="https://github.com/pypa/wheel-builders/pull/2">https://github.com/pypa/wheel-builders/pull/2</a></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 15, 2017 at 12:02 PM, Utkarsh Ayachit <span dir="ltr"><<a href="mailto:utkarsh.ayachit@kitware.com" target="_blank">utkarsh.ayachit@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>>   from vtkmodules import vtkSomeFactory<br>
>>   vtkSomeFactory.<wbr>SetDefaultClass("<wbr>vtkNameOfSomeClass")<br>
><br>
> This would be `from vtkmodules.vtkSomeModule import vtkSomeFactory`. The<br>
> point of vtkmodules is that the top-level package *doesn't* import<br>
> everything.<br>
<br>
</span>You can also:<br>
> from vtk import vtkSomeFactory<br>
>  vtkSomeFactory.<wbr>SetDefaultClass("<wbr>vtkNameOfSomeClass")<br>
<span class="HOEnZb"><font color="#888888"><br>
Utkarsh<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">+1 919 869 8849<br></div>
</div>