Is there a way to define "vtkEGLRenderWindow" as a variable in tox for CI use only, such that it can be reused, e.g. for the docstring/doctest workflow? I.e. address this comment #7861 (comment)

Maybe define CI_VTK_DEFAULT_OPENGL_WINDOW = "vtkEGLRenderWindow" as the variable in tox, and do something like:

alternatively, define a pre-command that checks if the env var CI is true, and if it is then export VTK_DEFAULT_OPENGL_WINDOW = "vtkEGLRenderWindow"? This way we wouldn't need to define it as an env var inside the workflow itself, and would be self-contained inside the tox config.

We can also address this separately with a future PR that adds tox to the docstring tests

Is there a way to define "vtkEGLRenderWindow" as a variable in tox for CI use only, such that it can be reused, e.g. for the docstring/doctest workflow? I.e. address this comment #7861 (comment)

Don't think it's possible to set and env variable in tox depending on the value of another one (ie. CI)

alternatively, define a pre-command that checks if the env var CI is true, and if it is then export VTK_DEFAULT_OPENGL_WINDOW = "vtkEGLRenderWindow"? This way we wouldn't need to define it as an env var inside the workflow itself, and would be self-contained inside the tox config.

commands output cannot be captured in subsequent commands, so I don't think this is possible either.

Maybe through a dedicated homemade plugin ...

@user27182 does f7c8862 is what you intended ?

If yes, do you prefer cherry-picking f7c8862 inside another dedicated PR ?

And I went to verify it's working by checking the software report, but I guess there is none?? Or at least I couldn't find it. Maybe it was excluded with #7916 ?

Looks like we need to add that back in. We can open an issue or simply add it in this PR.

And I went to verify it's working by checking the software report, but I guess there is none?? Or at least I couldn't find it. Maybe it was excluded with #7916 ?

Fixed in 1a0e117

I see, then I guess we should include doctest-modules in the list of cases where we want to set VTK_DEFAULT_OPENGL_WINDOW? Is that correct, @akaszynski, we want these two workflows to use this consistently?

I'd say so. It's better to be explicit IMO to try to set the render window, and it's a bit of future proofing to ensure that should we decide to use a GPU in one of our workflows.

Done in d79dc41

And as an additional unrelated note, is it an easy change to exclude -v from the documentation image tests? I find the extra 5000 lines in the log for all the test cases to be unnecessary for this. (-v was not used for this prior to #7916)

Done in a834b43

Thanks @beroda ! I was expecting the report to include "vtkEGLRenderWindow" as the render window, but instead it's just a generic "vtkRenderWindow".
https://github.com/pyvista/pyvista/actions/runs/17657586560/job/50184056166#step:7:40

This does not appear to be specific to this workflow, it seems the unit tests, type checking, docstring tests also do not appear to be reporting a concrete render window class.

Thanks @beroda ! I was expecting the report to include "vtkEGLRenderWindow" as the render window, but instead it's just a generic "vtkRenderWindow". https://github.com/pyvista/pyvista/actions/runs/17657586560/job/50184056166#step:7:40

This does not appear to be specific to this workflow, it seems the unit tests, type checking, docstring tests also do not appear to be reporting a concrete render window class.

This is reported/tracked in #7948

With the fix from #7949 , on Windows unit tests we have Render Window : vtkOSOpenGLRenderWindow
https://github.com/pyvista/pyvista/actions/runs/17685334349/job/50268816978?pr=7949#step:7:57

This differs from the default of EGL set for the docs. Perhaps we want to use the same render window for all CI jobs, not just docs/docstrings? Not sure if that will cause any generated images will differ and introduce regressions... but if not perhaps we should consider doing so for consistency?