fix vtk version support

[akaszynski]

Resolves #2867 by implementing matrix testing for VTK and Python.

• Python 3.7 --> vtk==8.1.2
• Python 3.8 --> vtk==9.0.3
• Python 3.9 --> vtk==9.1
• Python 3.10 --> vtk==9.2.0

Additionally, because we aren't testing Python 3.7 with 8.1.2, we've had some VTK version support regressions only discovered when locally testing 3.7. This PR fixes those regressions.

---

Also, I propose that we support the oldest VTK version with a viable wheel available for actively supported versions of Python available on PyPI. For example, the lowest supported version of Python as of this PR is Python 3.7, and the lowest supported version of VTK for 3.7 is vtk==8.1.2.

This is reflected in the install_requires in our setup.py.

As soon as support for Python 3.7 is dropped, we can then drop support for both Python 3.7 and VTK 8.1.2 in both our python_requires and install_requires.

As much as I would prefer to follow NumPy's version support NEP 29 deprecation policy, I know of many who are stuck using older versions of Python and need support for older versions of VTK and cannot upgrade agressively. With this approach we can still depricate support for older versions of VTK and Python, but in a manner that works for all that use this library with any currently supported version of Python.

[codecov]

Codecov Report

Merging #2961 (f7d1df5) into main (c75d631) will decrease coverage by 4.27%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #2961      +/-   ##
==========================================
- Coverage   94.30%   90.02%   -4.28%     
==========================================
  Files          76       76              
  Lines       16565    16569       +4     
==========================================
- Hits        15622    14917     -705     
- Misses        943     1652     +709     

[MatthewFlamm]

This, in general, looks good to me. Maybe for a future PR: we mix skipping tests completely and checking that we raise with VTKVersionError in the code base. In my opinion it would be better to check that it raises to make sure that we handle these cases with useful errors.

[MatthewFlamm]

Does setup.py support <=9.2.0.*?

[akaszynski]

I was having trouble permitting a release candidates with any version range unless you specifically permit it, as in:

pyvista/setup.py

Lines 21 to 22 in 88a8940

	'vtk>=8.1.2, <=9.2.0; python_version < "3.10"',
	'vtk>=8.1.2, <=9.2.0, ==9.2.0rc1; python_version == "3.10"',

What I did was explicitly permit the release candidate wheel, but only for Python 3.10. Personally, I don't feel that release candidates should be permitted by default, but only in special circumstances like general unavailability otherwise as in the case of Python 3.10

[MatthewFlamm]

This makes sense to me. Ideally the rc part could be removed before the release in pyvista. If it can't, should we use some form of ==9.2.0.*, so that later release candidates can be used? I'm not sure. Maybe best to pin it and manually keep updating it until the release? This way there are no surprises.

[akaszynski]

If it can't, should we use some form of ==9.2.0.*, so that later release candidates can be used?

If someone knows how to get release candidates working with a version range, please let me know. Otherwise, I'll permit ==9.2.0rc for PyVista for now.

[MatthewFlamm]

See my other suggestion, if that doesn't work, I'm in favor of ==9.2.0rc1 and manually bumping it as needed, and hopefully removing it before next release (vtk had a 1 month release cycle last time).

[akaszynski]

Agreed then. Let's keep to this for now and hopefully 9.2.0 is out before the next release of PyVista.

[akaszynski]

This, in general, looks good to me. Maybe for a future PR: we mix skipping tests completely and checking that we raise with VTKVersionError in the code base. In my opinion it would be better to check that it raises to make sure that we handle these cases with useful errors.

Agreed, that seems like a better practice.

[MatthewFlamm]

Should we also pin python_requires to be <= 3.10?

[akaszynski]

Should we also pin python_requires to be <= 3.10?

I'm not sure. I don't see an upper limit for numpy, and I think that we should permit those who want to use PyVista with an unsupported version of Python.

[akaszynski]

This is ready for review/approval. Checking showing up as yellow just means we need to update our branch protection rules once this PR is merged.

[MatthewFlamm]

LGTM.