Deprecate non-Trame Jupyter backends

[banesullivan]

The final step to resolve #3690 -- deprecates all previous notebook backends in favor of the new Trame-based backend.

[banesullivan]

@pyvista/developers, I'd like to land this for 0.38 but if there are reservations about deprecating all other backends so quickly after the introduction of the new Trame-based backend, we can delay this to 0.39

[codecov]

Codecov Report

Merging #3902 (67588cb) into main (6884399) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #3902   +/-   ##
=======================================
  Coverage   94.19%   94.20%           
=======================================
  Files          91       91           
  Lines       19583    19632   +49     
=======================================
+ Hits        18447    18494   +47     
- Misses       1136     1138    +2     

[larsoner]

I think we need #3879 first, and maybe also the code to tell people nicely when a plot isn't expected to work (volume rendering or whatever?)

[banesullivan]

I think we need #3879 first,

On its way, but I need land #3889 and #3897 first. Do you think you could help review those?

maybe also the code to tell people nicely when a plot isn't expected to work (volume rendering or whatever?)

At this point, the trame-client side backend is better supported and more feature rich than any of the other backends. There are no longer any features (that I'm aware of) that are support by other backends and not the trame backend.

FYI, volume rendering works fine now! (ref Kitware/trame-vtk#19)

[akaszynski]

I'm happy to change the backend default, especially now that volume rendering works by default.

We can always submit a patch release should we need to revert.

[akaszynski]

Fairly sure that warnings from the docbuild are difficult to suppress: https://github.com/sphinx-doc/sphinx/pull/11024/files

[banesullivan]

Erm... Should I just remove where these backends are used in examples?

[akaszynski]

Erm... Should I just remove where these backends are used in examples?

I'd advocate for a soft deprecation here. If we want to, we can include a note or warning directive to indicate that these are being replaced. This will give users a chance to see and compare the new vs. the old.

[akaszynski]

Ironically, the brand new jupyter backend doesn't support the coolest feature we have: being able to visualize in static webpages.

I'd really like to make sure we don't block the usage of these alternative backends until we can be feature parity.

[banesullivan]

Ironically, the brand new jupyter backend doesn't support the coolest feature we have: being able to visualize in static webpages.

I'd really like to make sure we don't block the usage of these alternative backends until we can be feature parity.

We'll have the static output from trame in the next couple weeks... we could just land this PR after 0.38 so that the deprecation comes with that final feature

[akaszynski]

We'll have the static output from trame in the next couple weeks... we could just land this PR after 0.38 so that the deprecation comes with that final feature

Awesome.

[banesullivan]

with #3909 and soon-to-come static embedding, what do you think @akaszynski? Merge for 0.38 or wait for 0.39?

[akaszynski]

with #3909 and soon-to-come static embedding, what do you think @akaszynski? Merge for 0.38 or wait for 0.39?

I'm good with merging this now. Users can still use the older backends, even without warnings since we suppress those.