FS#48113 - [vtk] support for python 3

Attached to Project: Community Packages
Opened by sdfdsfsdf (dekece) - Wednesday, 10 February 2016, 07:58 GMT
Last edited by Bruno Pagani (ArchangeGabriel) - Tuesday, 04 September 2018, 14:23 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Evgeniy Alexeev (arcan1s)
Bruno Pagani (ArchangeGabriel)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No

Details

Description:

VTK 7 now adds support for python3, but I don't see it in the files of the packages or in the dependencies.
Would it be possible to re-build it with support for both python 2 and 3 if possible?
This task depends upon

This task blocks these from closing
 FS#58364 - [mayavi] Segfaults upon starting 
Closed by  Bruno Pagani (ArchangeGabriel)
Tuesday, 04 September 2018, 14:23 GMT
Reason for closing:  Implemented
Additional comments about closing:  VTK 8.1.1-1 in [community].
Comment by Anatol Pomozov (anatolik) - Thursday, 11 February 2016, 00:42 GMT
Could you please provide information how to build both python2 and python3 support? I can't find it in the VTK sources.
Comment by sdfdsfsdf (dekece) - Thursday, 11 February 2016, 08:50 GMT
You got me, I did not try to build it.
But anyway, according to their blog release here https://blog.kitware.com/vtk-7-0-0/ it is a matter of setting VTK_PYTHON_VERSION in the cmake build file.
You might have to do vtk-python2 and vtk-python separate packages for this one, sorry for the maintenance burden :/
Comment by Anatol Pomozov (anatolik) - Thursday, 11 February 2016, 11:24 GMT
Setting VTK_PYTHON_VERSION will probably work. By default if it is not set and both python2 and python3 present in the environment VTK build system chooses python2. And it is what we have in vtk build right now.

But it is much better if the build system allow to build *both* python versions bindings at the same time. I suggest to make an upstream request for this.
Comment by sdfdsfsdf (dekece) - Thursday, 11 February 2016, 12:39 GMT
Now we just have to see what they think about it.

http://www.vtk.org/Bug/view.php?id=15991
Comment by sdfdsfsdf (dekece) - Saturday, 13 February 2016, 10:59 GMT
Aparently they have been discussing it for a while, but nobody reached an agreement on how to do it.
Comment by sdfdsfsdf (dekece) - Sunday, 21 February 2016, 17:25 GMT
Since upstream might take long to fix, would it be possible to have something like vtk python 3 binding from the package itself with another package python2-vtk providing only python2 binding (or the opposite if something depending on vtk needs python2 and have a python-vtk package)?

If you would need to rebuild the whole thing completely for the bindings then it would be useless, but if not it would give a nice compromise for the time being.
Comment by Anatol Pomozov (anatolik) - Sunday, 21 February 2016, 21:23 GMT
You are free to add an AUR package for these bindings. If it becomes popular we might consider moving it to official repo.
Comment by Elvis Stansvik (estan) - Saturday, 28 May 2016, 15:50 GMT
In my case, I was only interested in Python 3 bindings and made my own vtk-python3 package (see attached .tar.gz), which then conflicts with the vtk package.

I unfortunately don't feel like I have the time to take on responsibility for maintaining this package on the AUR, but if anyone feels like doing so, please go ahead.

Apart from the Python 3 changes, there were a couple of things I had to do to make the package build:

- Add the following two upstream patches:
- https://gitlab.kitware.com/vtk/vtk/commit/52501fd085a64b55d1b53d40c1d3f86c6ce9addd
- https://gitlab.kitware.com/vtk/vtk/commit/06e2a00bf8accb04db63b3c1c7a454e4afc6fea6

- Use -DVTK_USE_SYSTEM_HDF5=OFF, thereby (unfortunately) using the bundled HDF5, because of HDF5 API changes in 1.8.x -> 1.10.x.
Comment by Alex Maystrenko (technic93) - Monday, 05 September 2016, 12:22 GMT
thanks to @estan, I've added it to aur https://aur.archlinux.org/pkgbase/vtk-py3-qt4/
Comment by Oli (b52) - Monday, 09 January 2017, 21:10 GMT
What's the state on this one? What about splitting the package into vtk, python2-vtk and python-vtk. The two latter ones should depend on the first one, but it should be possible to solve both in one PKGBUILD.
Comment by Alex Maystrenko (technic93) - Monday, 09 January 2017, 21:52 GMT
It is not possible. For python3 you should rebuild from the beginning.
Comment by Oli (b52) - Monday, 09 January 2017, 22:36 GMT
Come again, why is it is not possible? Should be quite trivially, building two versions and package parts individually.
Comment by Anatol Pomozov (anatolik) - Tuesday, 10 January 2017, 00:00 GMT
Oli, patches are welcome.
Comment by Oli (b52) - Tuesday, 10 January 2017, 13:04 GMT
Current approach looks something like https://paste.xinu.at/aAI/ , yet, the python2 package doesn't work. Turns out `libvtkFiltersPython.so.1` has no Python specific suffix, thus I can't bundle it in python-vtk and python2-vtk. At this point I'm not sure if it is possible run both versions side by side.
Comment by Oli (b52) - Tuesday, 10 January 2017, 13:17 GMT
Furthermore, why I was wondering why you use python2 as default? I mean the default python version in Arch is 3.x, the sane default would be to use the default python version of the distro if it is supported by the software.
Comment by Elvis Stansvik (estan) - Tuesday, 10 January 2017, 17:49 GMT
@Oli: Regarding libvtkFiltersPython, see this thread on VTK mailinglist:

http://public.kitware.com/pipermail/vtkusers/2015-October/092423.html

especially these answers from David Gobbi and Ben Hoeckel from Kitware:

http://public.kitware.com/pipermail/vtkusers/2015-October/092442.html
http://public.kitware.com/pipermail/vtkusers/2015-October/092463.html

In short, it seems versioning of some Python stuff was overlooked, and as a packager you would need to do it manually in order for packages not to conflict.

I'd also suggest patching VTK to not use .1 as the version in the .so file names, but use the major/minor versions of VTK. See 20_soversion-sharedlib.patch in the Ubuntu package of VTK 6 for how to do that (but the same is true for VTK 7, this is what I do in our company-internal Ubuntu packaging of VTK 7).
Comment by Oli (b52) - Wednesday, 11 January 2017, 12:10 GMT
Right, but it seems Ben Hoeckel raised a valid concern:
https://gitlab.kitware.com/vtk/vtk/merge_requests/729#note_36649

Not sure this is easy to fix. It's indeed easy to adjust all the suffixes, but it's not clear to me how to tell other components like e.g. VTK_RENDERING_BACKEND.

The .so major/minor version patch is actually a good point.
Comment by Elvis Stansvik (estan) - Wednesday, 11 January 2017, 12:31 GMT
@Oli: Ah, indeed, that poses a problem :/ I have no good answer, perhaps the best thing is to simply make two conflicting packages (vtk-python3 and vtk-python2), and bring up the questions of simultaneous builds / coinstallability with the VTK devs again. Seems the upstream changes required are non-trivial to say the least.
Comment by Oli (b52) - Wednesday, 11 January 2017, 13:21 GMT
I now do have a version that works side-by-side using Python 2 and 3. PKGBUILD and patches are here:
https://paste.xinu.at/KBWZw/

I ran a simple test script (http://www.vtk.org/Wiki/VTK/Examples/Python/Graphs/VisualizeGraph) and it worked flawlessly. Maybe someone else can do a bit more testing?

The AUR package is located here: https://aur.archlinux.org/pkgbase/vtk-multi-python/
Comment by Elvis Stansvik (estan) - Thursday, 12 January 2017, 07:35 GMT
Oki: That's very cool. Wish I could give it a spin, but I only have Arch on my personal laptop and its CPU fan recently died on me. I only have my Kubuntu work laptop at the moment :/

What would be great is if there was a way to run all the Python tests against your installed version, but maybe that's not possible/easy.
Comment by Kevin Zhao (Jesse2004) - Sunday, 31 December 2017, 14:46 GMT
+1 for this issue. Separate (maybe mutually conflicting) packages should be provided for python 2/3.
Comment by Andrzej Giniewicz (Giniu) - Friday, 01 June 2018, 07:49 GMT
python bindings of vtk are for now only used by mayavi (at least in community). New version of mayavi (4.6.0) can be built using python3 and qt5 - maybe at least it is time to switch the default python bindings? Anyone else depends on python2 vtk bindings?
Comment by Gerhard Bogner (slashME) - Tuesday, 07 August 2018, 08:11 GMT
This is a PKGBUILD for vtk with python 3.7 bindings based on this package.
   PKGBUILD (2.3 KiB)
Comment by Bruno Pagani (ArchangeGabriel) - Thursday, 16 August 2018, 14:55 GMT
Building on python 3 is not a difficulty, we already do it for paraview.

If we can get mayavi to build with python 3, we should probably just move entirely to that instead of having another version to support python 2 as well. We will discuss that amongst involved packagers.
Comment by Andrzej Giniewicz (Giniu) - Thursday, 16 August 2018, 19:47 GMT
I'd vote for moving vtk to python3, not matter the state of mayavi. If I won't be able to fix it (it is broken anyway for some time) it would be better to move mayavi to AUR and move it back to community when it is fixed. People should be able to build mayavi on their machines without chroot, so AUR is an option here.
Comment by Bruno Pagani (ArchangeGabriel) - Friday, 17 August 2018, 15:43 GMT
I’m updating to Python 3 now.
Comment by Bruno Pagani (ArchangeGabriel) - Friday, 17 August 2018, 23:09 GMT
Package is in [community-testing], please test it and report any issue.
Comment by Bruno Pagani (ArchangeGabriel) - Thursday, 23 August 2018, 17:38 GMT
The package will soon be moved to [community] even if there is no feedback (that is as soon as the hdf5 rebuild is done).

Loading...