[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