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

[David Gobbi]

After taking a break for the weekend, I'm back into the ring on this one.

Prabhu Ramachandran wrote:

>"David" == David Gobbi <dgobbi at atamai.com> writes:
>
>    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.
>  
>
You are misunderstanding me on one of my points here.  I'm not saying that
we should change the behaviour of distutils.  I'm just saying that when 
we run

  python setup.py install --prefix=$pth

setting --prefix=${CMAKE_PREFIX} is not always the best choice.  Remember
that by default, distutils sets the prefix to python's install prefix.  
You say that's
bad because python's prefix is usually /usr.

My main concern is for people who are either first-time Python users or who
only ocassionally use python.  I think that the default configuration 
should be
set up to make life easy for those users.

The largest class of these users is probably Windows-users who are 
taking VTK
for a test-drive.  They are likely to have installed Python themselves.
For these users, installing into python's site-packages, as opposed to the
CMAKE_PREFIX, makes a lot of sense.

>    >> 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.
>  
>
I said that VTK_PYTHON_SETUP_ARGS should _not_ be advanced.  CMake
should show the user very clearly where these python modules are going to
be installed, so that the user immediately understands that he/she has 
an option
to install them somewhere else.

>    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.
>  
>
It is not a Linux issue, all UNIX variants are the same as far as 
intalling in /usr
is concerned.

Really it is an oversight on the part of the part of the python folks 
that distutils
will install packages in /usr/ by default and that python does not 
search in /usr/local
by default.  Maybe you debian folks can talk some sense into them.

>    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.
>  
>
This would work.

We have to move forward here.  I have a proposal:

1) Make VTK_PYTHON_SETUP_ARGS so that it is not advanced.  This will make it
obvious to the user that they have an option about where the python 
modules are
installed.  The "Help" tag should indicate that /usr/local and /usr are 
other possible options.
We don't want to be dictators.

2) adopt your vtkversion strategy

The third thing that should be done, eventually, is that CMake should 
create a shell
script that the user can source to automatically set the PYTHONPATH 
variable.  This
will be useful particularly for people that just do "make" and not "make 
install".

- David