Let matplotlib choose its default backend

[prasad-sawantdesai]

batch node test

  (myenv) [sawantp1@98dci4-clu-3010 IDStools]$idsprint --uri "imas:hdf5?path=/work/imas/shared/imasdb/ITER/3/134174/117#core_profiles/profiles_1d[0]/electrons/temperature" -p
  10:30:26 INFO     Parsing data dictionary version 3.38.1 @dd_zip.py:89
  ----> Figure saved to idsprint_PATH__work_imas_shared_imasdb_ITER_3_134174_117_.png
  (myenv) [sawantp1@98dci4-clu-3010 IDStools]$ echo $MPLBACKEND

[SimonPinches]

Have we tested with ipympl inside a Jupyter/JupyterHub?

[prasad-sawantdesai]

Have we tested with ipympl inside a Jupyter/JupyterHub?

Yes,

[SimonPinches]

Moving this to a function-local import (inside _is_interactive_backend, which is the only place it's used) would avoid a subtle problem: the entry scripts import clihelper before idstools.view.common, and the --rc backend=... mechanism from PR #33 relies on setting MPLBACKEND before matplotlib's first import (matplotlib only reads that env var at import time). With this top-level import, matplotlib now gets imported before _backend_from_cli_rc runs, so --rc "backend=..." (including the examples added in jupyter.rst) is silently ignored for early backend selection. I verified this with matplotlib 3.8.2: MPLBACKEND set after import matplotlib has no effect, and switching rcParams["backend"] later doesn't convert already-created figure canvases.
I think we should re-test the two --rc examples in the new docs and confirm they actually produce an interactive (draggable/zoomable) figure rather than a static one?

[SimonPinches]

This duplicates _is_jupyter() from idstools/view/common.py (line 35): Could we import it from there instead (from idstools.view.common import _is_jupyter)? No circular-import risk since view/common.py doesn't import clihelper, and as a bonus, importing view.common here would run its _backend_from_cli_rc env setup before matplotlib's first import, which would also solve the --rc backend ordering issue flagged above.

One drawback however is that importing view.common from clihelper means every clihelper user pays the cost of importing matplotlib.pyplot and the style setup at import time. If that's a problem, the cleaner alternative would be to move _is_jupyter (and the _backend_from_cli_rc env logic) into a small shared module with no pyplot dependency, and keep the matplotlib import in clihelper function-local. That's more work though!