[vtk-developers] Re: VTK Python Installation [was: VTK 5.0 branch in mid-August]

[Prabhu Ramachandran]

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

    Brad> Prabhu Ramachandran wrote:
    >> Still a hack, still needs hard coded paths.

    Brad> Where are you guys seeing a hard-coded path in the itkbase
    Brad> design?  The whole point of it is to allow the binary to be
    Brad> distributed and executed from anywhere.  When I first wrote
    Brad> it I put it on the ITK 1.6 CD and python scripts could be
    Brad> executed by drag-and-drop onto the executable on the CD in
    Brad> whatever drive it was sitting or in whatever path to which
    Brad> the user had copied it.

    Brad> The installed version of itkbase.py gets this package
    Brad> directory:

    Brad>    SET(ITK_CSWIG_PACKAGE_DIR "os.path.dirname(selfpath)")

Hmm, I thought ITK_CSWIG_PACKAGE_DIR was a hard-coded path (I don't
use ITK).  Why do you need this defined at all then?  Why not have
this in itkbase.py:

  pkgdir = os.path.dirname(selfpath)

To get this working with McMillan's installer will require a little
more work because __file__ is not available when the import hooks are
used.  I suspect this is what Charl was referring to.  However, it is
possible to work around this.

    Brad> This allows it to compute the location of the rest of the
    Brad> python wrappers wherever it may be.  Then you just have to
    Brad> build with CMAKE_SKIP_RPATH set to ON and the installation
    Brad> will have no reference to the original build tree.

Under *nix, does this require that rpath be set with '.' in the rpath?
Will the os.chdir approach work at all if CMAKE_SKIP_RPATH is ON?

If it does depend on rpath then, this is not acceptable.

    >> 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.

    Brad> The itkbase design allows a binary to be extracted from a
    Brad> tarball and executed out-of-the box without setting any PATH
    Brad> or LD_LIBRARY_PATH.  I do not see how the Apple design
    Brad> addresses this.  When the .so is loaded how does it find its
    Brad> ...D.dylib libraries?

I just read David's response and he expresses my concern a lot better.

[...]
    Brad> Not with the itkbase.py design.  It requires only PYTHONPATH
    Brad> to be set.
    Brad>   With my suggestion for stub packages in site-packages then
    Brad>   you don't
    Brad> even need to set anything.

>From what I understand the os.chdir() trick works because of either
rpath or a hard-coded path.  If I am wrong then this is worth
considering.

    >> BTW, since VTK-5.0 is anyways backwards incompatible in many
    >> ways, how about removing the backwards compatibility layer of
    >> vtkpython.py, vtkpythontk.py, vtkRenderWidget.py, etc.?

    Brad> That sounds good to me.

OK.  Thanks!

cheers,
prabhu