[vtkusers] Help building Python wheels for VTK

[David Gobbi]

On Tue, Aug 5, 2014 at 6:59 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> On Tue, Aug 05, 2014 at 04:25 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> On Tue, Aug 5, 2014 at 5:02 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>>> Yes, in principle it's possible to create a directory with the correct
>>> structure, then pack it into a zip file.  Did you have a chance to look
>>> at the wheel file format?  Basically someone (oh dear is that me?) needs
>>> to move all the files that need installing into that directory tree in
>>> the correct places, and record the manifest etc in the RECORD, WHEEL and
>>> METADATA sections, then zip it up with the right filename.  Maybe if you
>>> could come up with a list we can see if we can get somewhere...
>>
>> I glanced at the two PEPs.  CMake can be told where to put the python
>> modules via the VTK_INSTALL_PYTHON_MODULE_DIR variable, but
>> that by itself is probably not sufficient.
>
> So the wheel usually consists of the package directory as it will be
> copied into the Python installation - I guess VTK in your case, and then
> a (say) VTK-<version>.data directory with files that need to be copied
> elsewhere in the file system, and then the housekeeping stuff like the
> manifest and so on.  So, if VTK only installs file into the VTK Python
> package directory, then that would be almost enough.

The relevant parts of VTK install tree look like this (on OS X):

${VTK_INSTALL_PYTHON_MODULE_DIR}/vtk/(*.py|*.pyc|*.so)
share/vtk-6.2/vtkDomainsChemistry/elements.xml
lib/*.dylib

Let me look at the wheel structure more closely, and I'll get back to you
with some info on how CMake can be coerced to make the job easier.

>> One tricky thing, of course, is that the python modules depend upon the
>> VTK dylibs, and I'm not clear on how relocation is to be handled.  Do the
>> wheel tools have the ability to change the loader path of shared objects?
>> Will the dylibs always be placed at a known location relative to the
>> installed python .so files?
>
> I wrote an OSX utility to copy / relocate dynamic libs for OSX called
> delocate [1] - so we could at least handle OSX that way.
> [1] https://pypi.python.org/pypi/delocate

That could definitely be useful.  CMake can also inject the path during
the build process, if we end up with cmake building the wheel directly.

 - David