[vtk-developers] python install prefix in setup.py
Prabhu Ramachandran
prabhu_r at users.sf.net
Sat Feb 4 00:51:43 EST 2006
>>>>> "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
More information about the vtk-developers
mailing list