Describe the bug
The get_backend() function in python/grass/jupyter/interactivemap.py has an issue in how it handles import failures. If importing folium fails, the function immediately returns "ipyleaflet" without actually checking whether the given object is an ipyleaflet.Map.
This means the backend is sometimes guessed instead of being determined based on the actual object type, which can lead to incorrect behavior in downstream map operations.
To reproduce
- Create a
folium.Map object
- Simulate a situation where
folium cannot be imported (for example, by mocking sys.modules)
- Call
get_backend() with that object
- The function returns
"ipyleaflet" even though the object is not an ipyleaflet.Map
Expected behavior
Ideally, the function should:
- Check the type of the object before deciding the backend
- Try both
folium and ipyleaflet (if available) instead of assuming
- Not rely on import failure as a signal for backend type
- Raise a
ValueError or return a clear fallback (like "unknown") if the type cannot be determined
Screenshots
Not applicable — this is a logic issue.
System description
- Operating System: Windows
- GRASS version: 8.4.2
- Python: 3.12+
Additional context
This came up while writing tests for get_backend(). While mocking import failures, it became clear that the function skips proper type checking and falls back to assumptions.
Since this function is used internally by grass.jupyter.InteractiveMap (for example when adding raster or vector layers), incorrect backend detection could lead to subtle bugs, failed renders, or unexpected crashes when dependencies are missing or partially available.
Describe the bug
The
get_backend()function inpython/grass/jupyter/interactivemap.pyhas an issue in how it handles import failures. If importingfoliumfails, the function immediately returns"ipyleaflet"without actually checking whether the given object is anipyleaflet.Map.This means the backend is sometimes guessed instead of being determined based on the actual object type, which can lead to incorrect behavior in downstream map operations.
To reproduce
folium.Mapobjectfoliumcannot be imported (for example, by mockingsys.modules)get_backend()with that object"ipyleaflet"even though the object is not anipyleaflet.MapExpected behavior
Ideally, the function should:
foliumandipyleaflet(if available) instead of assumingValueErroror return a clear fallback (like"unknown") if the type cannot be determinedScreenshots
Not applicable — this is a logic issue.
System description
Additional context
This came up while writing tests for
get_backend(). While mocking import failures, it became clear that the function skips proper type checking and falls back to assumptions.Since this function is used internally by
grass.jupyter.InteractiveMap(for example when adding raster or vector layers), incorrect backend detection could lead to subtle bugs, failed renders, or unexpected crashes when dependencies are missing or partially available.