VTK 9.2.6 brings OSMesa wheel variants

[banesullivan]

With VTK 9.2.6, Kitware is now shipping an OSMesa wheel variant for manylinux: https://gitlab.kitware.com/vtk/vtk/-/packages/102

This is installable as (ignore the personal access token stuff on GitLab):

pip install vtk-osmesa --extra-index-url https://gitlab.kitware.com/api/v4/projects/13/packages/pypi/simple

To distinguish these wheel variants, the distribution name is vtk-osmesa, which does not match the vtk in PyVista's core dependencies. Care must be take to make sure you do not have both vtk-osmesa and vtk in the same environment. A simple, yet not pretty approach is to install PyVista, uninstall vtk, then install the OSMesa variant:

pip install pyvista
pip uninstall vtk -y
pip install vtk-osmesa --extra-index-url https://gitlab.kitware.com/api/v4/projects/13/packages/pypi/simple

Hopefully a future version of setuptools will make it easier for PyVista to specify different default installation requirements to streamline the installation of this OSMesa variant: pypa/setuptools#1139

Why is this useful

No more virtual framebuffers and no more apt installing! Goodbye xvfb!

The vtk-osmesa wheel bundles all the needed dependencies and is specifically for off-screen rendering. This wheel is optimal for managed, deployed environments like we often see on platforms like MyBinder, Heroku, Google Colab, SageMaker, etc.

Simply pip install this wheel for your JupyterLab environment and start using PyVista!

Further, this will make CI testing quite a bit easier for downstream projects

[banesullivan]

I also want to point any adventurous/brave developers to these CMake configurations if hoping to build OSMesa, EGL, or other build "variants" for other platforms: https://github.com/banesullivan/vtk-cmake

These configurations generally match the configurations used by VTK to publish the PyPI wheel

[banesullivan]

FYI, another status update: https://discourse.vtk.org/t/status-update-vtk-python-wheels/11212

[banesullivan]

These should be no longer relevant under the VTK 9.4 release which added support for OSMesa/EGL at runtime https://discourse.vtk.org/t/status-update-runtime-opengl-render-window-selection-in-vtk/14583

[MatthewFlamm]

Hopefully a future version of setuptools will make it easier for PyVista to specify different default installation requirements to streamline the installation of this OSMesa variant: pypa/setuptools#1139

There have been some subtle movements in this space, in particular PEP 735. This PEP allows for specifying dependencies groups in an orthogonal way to the extras. One of the use cases is listed as Data Science Projects, but the underlying idea is that there can be conflicting requirements for some packages. This is similar to what we have here. It is yet to be seen how pip and other toolchains will respond in supporting this kind of data.

This might be moot with newer versions of vtk, but at least as long as we support vtk versions <9.4, we will have to consider this.

[user27182]

Hopefully a future version of setuptools will make it easier for PyVista to specify different default installation requirements to streamline the installation of this OSMesa variant: pypa/setuptools#1139

There have been some subtle movements in this space, in particular PEP 735. This PEP allows for specifying dependencies groups in an orthogonal way to the extras. One of the use cases is listed as Data Science Projects, but the underlying idea is that there can be conflicting requirements for some packages. This is similar to what we have here. It is yet to be seen how pip and other toolchains will respond in supporting this kind of data.

This might be moot with newer versions of vtk, but at least as long as we support vtk versions <9.4, we will have to consider this.

We should also consider using this to "hide" the typing test and doc dependencies from front-end users (and consider doing so before the next pyvista release since this is new from #6753). These should not really be part of a public interface. I haven't read the PEP in detail but I think this is also an intended use-case, see
https://peps.python.org/pep-0735/#limitations-of-extras

[MatthewFlamm]

I agree, it is ideally suited for that use case.

[user27182]

PEP 735 is not yet supported by dependabot or pip, so we'll have to wait for this I think before we can use it.

dependabot/dependabot-core#10847
pypa/pip#12963