[vtk-developers] VTK 5.0 branch in mid-August

[Prabhu Ramachandran]

>>>>> "Brad" == Brad King <brad.king at kitware.com> writes:

    Brad> Prabhu Ramachandran wrote:
    >> I had plans to make some small changes to the Python extension
    >> modules.  The idea is to use the Apple approach, i.e. build a
    >> vtk*PythonD.so and install that along with the other VTK
    >> libraries and then build a separate vtk*Python.so that links to
    >> the vtk*PythonD.so.  This makes it much easier to install
    >> vtkpython.  However, this might be too much of a change, so I
    >> am willing to do this after 5.0 is released (maybe for 5.1).

    Brad> Take a look at how we do this in ITK:

Unfortunately, I don't approve of this approach for the following
reasons:

 1. AFAICT, this is a totally non-standard hack.  I've never seen a
    single Python package using os.chdir with a hard coded path to
    import extension modules.

 2. Using a hard coded path in a Python module and then relying on
    that to import extension modules is an error prone approach that
    will lead to lots of heartache.  This approach seems OK from the
    perspective of a VTK developer.  Most folks however would not
    enjoy, care for, or want to build VTK from sources.  For these
    folks binary installers are the only hope.  Using a hard coded
    path deep inside a Python module makes packaging such binaries a
    pain.  It also makes it impossible to make relocateable binaries.
    Think of tarballs that bundle the VTK-Python modules.  In order to
    work for everyone, these will require the user fiddling with the
    vtkbase.py (or whatever) and hardcode the location of the module.
    Things are hard enough as they are.
 
 3. Some folks (atleast Charl and I do) build standalone binaries of
    our Python code along with VTK-Python.  These will not work
    anymore (without more hacks) with this approach due to the
    non-standard nature of the hack.


OTOH, the Apple approach is simple and standard.  Build
libvtk*PythonD.so's and install them in the same place the other VTK
shared libraries (or dll's) are installed.  These libraries need to be
on the linkers path or on PATH (both are standard things that users,
packagers and admins know how to change).  Then build the
libvtk*Python.so extension modules that link to the
libvtk*PythonD.so's.  This is perfectly standard in the Python world.
These extension modules will be small so there is no significant space
overhead.

Thoughts?

cheers,
prabhu