MNT: Add support for PySide6

[GuillaumeFavelier]

This PR updates testing for PySide6, now that it is supported in vtk.

Related to #114

[codecov]

Codecov Report

Merging #147 (e0a35e0) into main (7c7ded8) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #147   +/-   ##
=======================================
  Coverage   97.87%   97.87%           
=======================================
  Files           8        8           
  Lines         658      658           
=======================================
  Hits          644      644           
  Misses         14       14           

[GuillaumeFavelier]

This annoying issue again:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/pyvista/__init__.py", line 14, in <module>
    from pyvista.core import *
  File "/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/pyvista/core/__init__.py", line 3, in <module>
    from .dataset import DataSet, DataObject
  File "/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/pyvista/core/dataset.py", line 7, in <module>
    from typing_extensions import Literal # for python versions <3.8
ModuleNotFoundError: No module named 'typing_extensions'

It's not related to the PR, I'll keep going.

[GuillaumeFavelier]

Everything on pyvista 0.32 fails but this is not relevant. The interesting part is:

Run pytest -v --cov pyvistaqt --cov-report html
INTERNALERROR> Traceback (most recent call last):
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/_pytest/main.py", line 264, in wrap_session
INTERNALERROR>     config._do_configure()
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/_pytest/config/__init__.py", line 992, in _do_configure
INTERNALERROR>     self.hook.pytest_configure.call_historic(kwargs=dict(config=self))
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/pluggy/_hooks.py", line 277, in call_historic
INTERNALERROR>     res = self._hookexec(self.name, self.get_hookimpls(), kwargs, False)
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/pluggy/_manager.py", line 80, in _hookexec
INTERNALERROR>     return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/pluggy/_callers.py", line 60, in _multicall
INTERNALERROR>     return outcome.get_result()
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/pluggy/_result.py", line 60, in get_result
INTERNALERROR>     raise ex[1].with_traceback(ex[2])
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/pluggy/_callers.py", line 39, in _multicall
INTERNALERROR>     res = hook_impl.function(*args)
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/pytestqt/plugin.py", line 203, in pytest_configure
INTERNALERROR>     qt_api.set_qt_api(config.getini("qt_api"))
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/pytestqt/qt_compat.py", line 104, in set_qt_api
INTERNALERROR>     self.QtGui = _import_module("QtGui")
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/pytestqt/qt_compat.py", line 100, in _import_module
INTERNALERROR>     m = __import__(_root_module, globals(), locals(), [module_name], 0)
INTERNALERROR> ImportError: libEGL.so.1: cannot open shared object file: No such file or directory

The goal is to make this one happy. Could it be because of qtpy-master? 🤔

Locally, on my linux system, everything works fine. I'll continue to investigate later.

[larsoner]

I saw CIs failed so I pushed. Let's see if it works !

[GuillaumeFavelier]

good idea @larsoner , I think it worked!

[larsoner]

Can you fix the CIs here, too? I guess it would mean just drop pyvista-0.32 from the CI matrix.

[GuillaumeFavelier]

We could but the goal was to test against previous versions... 😅

[larsoner]

We could but the goal was to test against previous versions...

Agreed, but it looks like PyVista 0.32 is just broken. Unless maybe it's only broken on 3.9+ or something, so we need to test it on a different version of Python for that build? Or maybe we need to install some library that's missing? Fixing the build is a better option if it can be done in one of these ways. But I don't think having CIs around that we know will always fail is a good option...

[GuillaumeFavelier]

Okay then I'll put this on hold the time for me to fix pyvista 0.32. I think it's the cleanest way to approach this

I thought it was automagically fixed:

pyvista/pyvista#1997

[larsoner]

That PR was merged Jan 6 of this year. Latest 0.32 release on PyPi appears to be Sept 2021:

https://pypi.org/project/pyvista/#history

Is it possible that your pip install line that you thought worked in pyvista/pyvista#1997 (comment) might have just been a no-op because you had pyvista installed in editable mode while working on a branch that was version 0.32?

[larsoner]

... there also is this prerelease version, though https://pypi.org/project/pyvista/0.32.dev0/

Maybe that's what you installed?

[GuillaumeFavelier]

might have just been a no-op

I don't remember the exact circumstances but it's totally possible.

But what about the CIs? What changed that it complains suddenly?

[larsoner]

But what about the CIs? What changed that it complains suddenly?

New Python version -- looking back at a run from the last PR:

Successfully setup CPython (3.8.12)
Install dependencies with pip

This one:

Successfully setup CPython (3.9.10)
Install dependencies with pip

[larsoner]

I guess that wasn't the issue :(

I think the easiest thing to do is to actually release a corrected 0.32. It needs to be done at some point anyway...

I'm okay with merging this PR as is if you want, though, since it seems like a separate problem.

[GuillaumeFavelier]

typing_extensions is in the setup.py of pyvista 0.32.1, that's how it was solved.

[GuillaumeFavelier]

The PR is ready from my end @pyvista/pyvistaqt-admin

[larsoner]

Very straightforward in the end, thanks @GuillaumeFavelier !