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

Prabhu Ramachandran prabhu_r at users.sf.net
Wed Feb 8 01:30:03 EST 2006


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

    >>  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> You are misunderstanding me on one of my points here.  I'm
    David> not saying that we should change the behaviour of
    David> distutils.  I'm just saying that when we run
[...]
    David> The largest class of these users is probably Windows-users
    David> who are taking VTK for a test-drive.  They are likely to
    David> have installed Python themselves.  For these users,
    David> installing into python's site-packages, as opposed to the
    David> CMAKE_PREFIX, makes a lot of sense.

OK, so under win32 and maybe the Mac we can default to using
sys.prefix.  I'm not convinced about the Unix behavior since I think a
good package should do what it is told to do.  If I set
prefix=/usr/local I expect that nothing will be added into /usr/
behind my back.

    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> I said that VTK_PYTHON_SETUP_ARGS should _not_ be advanced.

Sorry, I had wanted to say VTK_PYTHON_SETUP_ARGS should *not* be
advanced (after all it is advanced currently!) but I guess there was
too much multitasking going on at my end.

    David> CMake should show the user very clearly where these python
    David> modules are going to be installed, so that the user
    David> immediately understands that he/she has an option to
    David> install them somewhere else.

OK.  Even if it is going to be made clear to the user that cmake will
install things in sys.prefix, it still causes problems for those who
need to build VTK in an RPM or deb.  I think things should be made as
easy as possible for these folks.  At least the special cases should
be documented prominently (README.packagers?).

    >> Then users simply do:
    >> 
    >> import vtkversion vtkversion.require('5.0')
[...]
    David> This would work.

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

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

OK.

    David> 2) adopt your vtkversion strategy

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

I think this sounds fine.  Only thing is I don't have the time for
this during this semester, so count me out of helping with an
implementation.

cheers,
prabhu




More information about the vtk-developers mailing list