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

Prabhu Ramachandran prabhu_r at users.sf.net
Tue Aug 2 02:25:43 EDT 2005


Hi Brad,

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

    Brad> Prabhu, I suggest the following approach.  We add CMake
    Brad> install rules that install the python wrappers into the VTK
    Brad> install tree.  Users may set PYTHONPATH to point at
    Brad> PREFIX/lib/vtk/python to use them.  This will be consistent
    Brad> with the Tcl install rules.  We then also provide a setup.py
    Brad> that can be run in the python convention that either copies
    Brad> the VTK wrappers over to the python install location or just
    Brad> installs a few small stub .py files that forward the import
    Brad> over to the VTK location.

Still a hack, still needs hard coded paths.  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.

 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.

I'm sorry but this solution has always looked wrong to me.  Perhaps
this is the norm in the Tcl world, it is not so in the Python world.

I never approved of $prefix/lib/vtk/python anyway.  The first thing I
ever do when I need to install VTK somewhere was to move the extension
modules over to $prefix/lib and rm -rf the vtk/python directory.  I'd
then make symlinks from site-packages/vtk_python/ to these files.  The
symlinks are a hack and I don't like them either.  However, they
atleast don't take up space and I do recognize their status as an ugly
hack.  Essentially, vtk-python install was almost always either broken
or "hacked around".

I think the Apple approach resolves this whole mess in a clean fashion
that is packager friendly, sys-admin friendly, user friendly and
Pythonic.


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

I'm for eliminating all that and asking users to use the 'vtk'
package.  I'm probably the worst affected with MayaVi but I am willing
to fix that.

Comments?

cheers,
prabhu



More information about the vtk-developers mailing list