<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 6, 2015 at 12:06 PM, Ben Boeckel <span dir="ltr"><<a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
</span>All of VTK's modules should go to the archful directory (/usr/lib64 or<br>
/usr/lib/$triple). The .py files don't work without the .so files, so<br>
they all go to the same directory (e.g., on Fedora,<br>
/usr/lib64/python2.7/site-packages/vtk/*).<br>
<br>
Python 3.3 introduced namespace packages where you can split a module<br>
over multiple directories, but this is generally intended for the "find<br>
all submodules of foo" use case for plugins where the foo package has a<br>
presence on the archless and archful system directories as well as<br>
$PYTHONPATH. But this is not the use case for VTK, so dropping the .py<br>
files beside the .so files should be the way to go.<br></blockquote><div><br></div><div>Yes, the best way forward is probably to make it so that, during the build,</div><div>the Python .so modules go to "${VTK_BUILD_DIR}/Wrapping/Python/vtk/".</div><div>Currently the build drops them into the "lib" dir, but they're not libraries.</div><div><br></div><div>We could also make the python "vtk" module more efficient by dropping</div><div>the useless ".py" files (vtkCommonCore.py et al). These files only exist</div><div>because, historically (many many years ago), the VTK python extension</div><div>modules were named differently on Windows as compared to UNIX. It</div><div>would make more sense for vtk/__init__.py to load the .so files directly.</div><div><br></div><div>There is also an opportunity to rename the files. Instead of this:</div><div><br></div><div> vtkCommonCorePython.so</div><div><br></div><div>for VTK 7 we could change the name to one of these:</div><div><br></div><div> vtkCommonCore.so or simply CommonCore.so</div><div><br></div><div>I'm a fan the former, for the sake of backwards compatibility. In any case,</div><div>once the build location is moved, setting up the relative imports for Py3k</div><div>builds is trivial.</div><div><br></div><div> - David</div><div> </div></div></div></div>