[vtk-developers] python install prefix in setup.py

[Prabhu Ramachandran]

>>>>> "David" == David Gobbi <dgobbi at atamai.com> writes:

    David> I disagree that we should install to
    David> ${CMAKE_PREFIX}/lib/pythonx.x/site-packages, as is
    David> currently done.  It might make sense to install in
    David> ${CMAKE_PREFIX}/lib/vtkx.x/python
    >>  ${CMAKE_PREFIX}/lib/vtkx.y/python is completely non-standard.
    >> No Python module ever installs importable Python modules in
    >> lib/libname/python.  Any normal distutils based Python package
    >> is installed like so:
    >> 
    >> python setup.py install --prefix=$pth
    >> 
    >> and everything is installed in
    >> 
    >> $pth/lib/site-packages/pythonx.y/package

    David> Installing in $prefix/lib/pythonx.y/site-packages/ only
    David> makes sense to me when $prefix is one of the prefixes in
    David> site.prefixes, because those are the only prefixes that
    David> python knows to load modules from.

This is how distutils behaves and most Python users have adapted to
deal with this in one way or another via PYTHONPATH or
sitecustomize.py.

    David> There is one specific case when it is useful to install in
    David> $prefix/lib/vtkx.y/python, and that is when you want to
    David> install multiple versions of VTK in the same prefix without
    David> collisions.

For that we should instead use something along the lines of wxversion
or pygtk in order to pick a required version.  That said,
lib/vtk.x.y/python does not avoid any of the issues you raised with
lib/pythonx.y/site-packages/ either, it only breaks the standard.  So
I vote for breaking less standards given that there isn't a specific
advantage here.

    >> So, that is the default behavior of distutils.  What are you
    >> suggesting?
    >> 
    David> I'm suggesting that we provide the user with options.
    David> Also, the options should not be marked as "advanced"
    David> options in cmake, they should be clearly visible.

    David> The option would be called VTK_PYTHON_USE_DISTUTILS, it
    David> would be ON by default.

    David> If VTK_PYTHON_USE_DISTUTILS is ON, the option
    David> VTK_PYTHON_SETUP_ARGS will be present and will not be
    David> "advanced".  If ${CMAKE_PREFIX} is one of the prefixes in

+1 for making VTK_PYTHON_SETUP_ARGS advanced.  I am not sure that we
need a VTK_PYTHON_DISTUTILS at all.  Read on for reasons.

    David> site.prefixes, then it will be the default prefix.  This
    David> means that if CMAKE_PREFIX=/usr/local and /usr/local is in
    David> site.prefixes, everything works "out-of-the-box" after
    David> installation.  If ${CMAKE_PREFIX} is not in site.prefix,
    David> then the default prefix will be sys.prefix.  That will make
    David> things will work nicely for all superuser installs.

+1

Although, I've gotten used to Stow and totally disapprove of installs
made into /usr by non-package (i.e. non-deb/rpm) installs.  I guess,
on non-Linux platforms this is OK.

    David> If VTK_PYTHON_USE_DISTUTILS is OFF, then the modules will
    David> not be installed by distutils, but will instead be put in
    David> ${CMAKE_PREFIX}/lib/vtkx.y/.  There would be a CMake option
    David> PYTHON_INSTALL_PATH to allow the user to specify a
    David> different directory for installation.  Ideally VTK would
    David> produce a shell script that the user could source to set
    David> the PYTHONPATH and LD_LIBRARY_PATH.

Not sure about this one because it seems to make the install more
complex.  Right now we have a setup.py, next we'll have two separate
ways to install.  This looks like a maintenance headache.  From what I
can gather of your needs, you'd like a way to install the Python
modules such that you can keep multiple VTK installs handy.  What if
we simple invested in a vtkversion.py script that did this
automatically for us by the following approach:

 $prefix/lib/pythonx.y/site-packages/
                                      vtkversion.py
                                      vtk4.4/vtk
                                      vtk5.0/vtk
                                      vtkcvs/vtk
                                           

Then users simply do:

import vtkversion
vtkversion.require('5.0')

and vtkversion simply adds the right directory to sys.path and we are
set.

This is nice for several reasons.  (0) we still use distutils which is
still the current standard, (1) a few other projects do this so users
are familiar with this, (2) it makes it easy for apps to specify which
VTK they really need without the need for vtk.vtkVersion().GetFoo()
tricks.

Thoughts?

cheers,
prabhu