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
Opened by sdfdsfsdf (dekece) - Wednesday, 10 February 2016, 07:58 GMT
Last edited by Bruno Pagani (ArchangeGabriel) - Tuesday, 04 September 2018, 14:23 GMT
|
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
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].
Tuesday, 04 September 2018, 14:23 GMT
Reason for closing: Implemented
Additional comments about closing: VTK 8.1.1-1 in [community].
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 :/
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.
http://www.vtk.org/Bug/view.php?id=15991
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.
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.
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).
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.
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/
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.
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.