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

[Brad King]

Prabhu Ramachandran wrote:
>  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.
Charl P. Botha wrote:
 > Indeed.  When building standalone Python and ITK based binaries, I
 > have to hack around the hard-coded paths in the ITK Python
 > installation.  Not a biggie, but every extra piece of code is an extra
 > point of failure.
Prabhu Ramachandran wrote:
 > Still a hack, still needs hard coded paths.

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

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

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

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

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

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

 > Installing into
> $prefix/lib/vtk/python is broken for the following reasons:
> 
>  1. Non-standard.  I know of no other Python package that installs
>     extension modules in $prefix/lib/pkg/python.  I don't believe VTK
>     need be any different.  $prefix/lib/vtk/python is "neither here
>     nor there".  It isn't usually in ld.so.conf nor is it in
>     PYTHONPATH.

Not using vtk/python is fine with me, I was just copying the design from 
the Tcl wrappers.  But...how is one supposed to create a binary 
distribution that can be extracted to any location and run if some of 
the files are way off in a python site-packages directory?  This is why 
I think we should have a lib/vtk/python directory with a setup.py that 
does a "local install" to the site-packages directory for a particular 
machine.

>  2. I know of no (non-arch dependent/non-backwards compat. packages)
>     packages that install libraries that need to be in the linkers
>     path in $prefix/lib/pkg/python.  ATLAS and libc5 compatibility
>     libraries are notable exceptions.  Both are hacks and I'm willing
>     to agree that they might not have a choice.  I don't think VTK is
>     in that category.
> 
>  3. Not only do you need to set PYTHONPATH you also need to futz with
>     either /etc/ld.so.conf or LD_LIBRARY_PATH.

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

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

That sounds good to me.

-Brad