Switch to vtk version that supports aarch64 wheels in end user image

[schnellerhase]

vtk distributed wheels for aarch64 from version 9.5.0 onwards. This allows to switch back to pip installed dependencies for the lab image.

[jhale]

Let me know when this is ready and I can trigger a build for you.

[jhale]

Could you simply lower bound the version which you know has arm wheels? Then we can forget about it.

[schnellerhase]

Let me know when this is ready and I can trigger a build for you.

Sounds good, lets give it a try.

[schnellerhase]

Could you simply lower bound the version which you know has arm wheels? Then we can forget about it.

Then we should probably remove the version pin of pyvista as well, is that fine?

[jhale]

Yes, should be fine, I think it's pretty stable now.

[francesco-ballarin]

Please wait for pyvista/pyvista#7690 to be merged and released before triggering a docker image rebuild, because the current pyvista version is not compatible with the newest vtk.

[schnellerhase]

Current test run has a 'test' prefix - should not overwrite the images.

Should we then add 0.46 as a pyvista lower bound as well?

[schnellerhase]

Running import pyvista in the current container indeed breaks. Installing pyvista 0.46.dev0 (from main) works fine. Let's wait for the release.

[francesco-ballarin]

Should we then add 0.46 as a pyvista lower bound as well?

Don't think so. pyvista 0.45 (and possibly even lower) is still compatible with main, so anyone on amd64 arch would be able to use it successfully.

[jhale]

Reviewed and looks good - please merge once pyvista make a new release. There is only a need for a lower bound on vtk.

[francesco-ballarin]

There is only a need for a lower bound on vtk.

I don't think so. amd64 people can still use whatever vtk version is supported by pyvista, can't they? Linux aarch64 build will implicitly have a >=9.5.0, simply because no support existed before that version.

[jhale]

Quite possibly, as long as there are no source distributions for any version? Given that we're talking about something which is really an implementation detail, the explicit lower bound might still be best.