Repository navigation
Check vedo backends and document. #335
Description
On @paulbrodersen's machine, setting vedo.settings.default_backend = "vtk" is necessary to use brainrender. We should investigate why this is and make sure it's documented properly if others see the same behaviour.
Activity
paulbrodersen commentedon Apr 18, 2024
My conda environment specification, in case that helps. It's a YAML file, but I had to convert it to a text file to upload.
environment.txt
paulbrodersen commentedon Apr 18, 2024
paulbrodersen commentedon Apr 18, 2024
For some reason, the default backend is "2D" in my case.
paulbrodersen commentedon Apr 18, 2024
Hah, found the smoking gun!
I have been running code inside an ipython REPL, as I have been constantly inspecting brainrender objects and reading doc strings to wrap my head around how everything works together. Under these conditions,
import vedo; print(vedo.settings.default_backend)yields'2d'.However, iff I run code from the shell, i.e. outside the REPL, the backend defaults to
'vtk':paulbrodersen commentedon Apr 18, 2024
Re-raised the issue on the vedo issue tracker.
adamltyson commentedon Apr 18, 2024
Thanks for digging into this @paulbrodersen. Whatever the outcome is, this should be documented on the brainrender side.
paulbrodersen commentedon Apr 19, 2024
Looks like the problem is due to a too aggressive Jupyter notebook detection and is getting resolved on vedo's side.
paulbrodersen commentedon Apr 30, 2024
Issue should be resolved now: marcomusy/vedo#1108.
adamltyson commentedon Apr 30, 2024
@paulbrodersen thanks for looking into this. What do you think of this solution:
paulbrodersen commentedon May 1, 2024
I am paranoid, and people don't read documentation, so I would 1) have my own notebook detection that is triggered during import; 2) import vedo and check that it is using the right backend; 3) raise a warning if it is not with instructions on what steps will likely resolve the issue.
adamltyson commentedon May 1, 2024
Do we have any reason to believe that vedo is not doing this correctly (now) or that brainrender would be able to do it any better? I'm hesitant to add code to brainrender that really should be in (or already is in) vedo.
paulbrodersen commentedon May 1, 2024
No, and maybe?
Vedo is not numpy/scipy/matplotliblib, so my level of trust is lower and having a bit of defensive code around it seems like a worthwhile investment. Like so many libraries, it has been written and is being maintained by an army of one. And while the core vedo library code looks pretty decent, the project doesn't have CI, and the test suite seems to be patchy (at best) and require a human to check the results. My PR got merged within minutes, so I doubt it's been tested manually on more than one platform. (None of this is meant to be criticism of the vedo maintainer; it's just one of the realities of unpaid OSS development. Most of my libraries could do with better tests as well.)
I also think that this issue is particularly problematic, as no errors are raised when the backend is setup incorrectly. Most users won't even know where to start trouble-shooting. I also happen to maintain a data visualisation library, so a backend issue was one of my first guesses. But I doubt that will be the standard response.
Normally, one would have a regression test to ensure that a solved issue doesn't creep back in again. However, this issue can only be detected at runtime, so I don't see a fail-safe alternative to my proposal above. Of course, everyone has to pick their battles, and it might not be worth your time and effort to double-check that vedo is working as intended -- your call (but you did ask me for my opinion).
adamltyson commentedon May 2, 2024
I spent a while typing out a response to this, in which I stated that I thought it best to not add anything, and rely on this issue being fixed in vedo (thanks for that!).
However, in typing it out I changed my mind, so what I think is best is to:
[-]Document vedo backends[/-][+]Check vedo backends and document.[/+]