Initial matplotlib compat layer - #3394
Conversation
Introduce a new utility module that centralizes colormap access, listing, registration, and unregistration across Matplotlib API versions. The new helpers prefer modern `matplotlib.colormaps` APIs when available and fall back to legacy `matplotlib.cm`/`pyplot` behavior, with deprecation markers on legacy paths to support the migration.
Adds a `stacklevel` argument to `deeplabcut.core.deprecation.deprecated()` and uses it when emitting `DLCDeprecationWarning`. This keeps the default behavior (`stacklevel=2`) while allowing wrapper/legacy shim layers to bump the level so warnings point to the real caller.
Replaced direct `plt.cm.get_cmap(...)` calls across visualization and plotting modules with `deeplabcut.utils.matplotlib_future_mode.get_colormap`. This centralizes colormap access, keeps behavior consistent across TensorFlow/PyTorch/GUI/3D paths, and aligns with Matplotlib future-mode compatibility.
C-Achard
added
enhancement
deruyter92
modified the milestones:
Release matplotlib pin,
Refresh/bump core dependencies
…_names Previously it duplicated the legacy lookup inline (list(plt.colormaps())) instead of calling the @deprecated-decorated _legacy_get_colormap_names(), so the deprecation warning never fired on old Matplotlib installs, unlike register_colormap/unregister_colormap.
_legacy_register_colormap/_legacy_unregister_colormap/_legacy_get_colormap_names now report their public wrapper names (e.g. register_colormap) in deprecation warnings instead of the private helper name.
update all import sites accordingly
|
@C-Achard, great efforts, good plan. When working on this PR myself as well, I realized that adding a whole compat layer might not be necessary if the single solution it might be helpful to merge #3430 first! |
|
(pushed my additional changes now but feel free to revert) |
There was definitely some future-proofing/extra caution in doing it this way, as I was concerned we may uncover other matplotlib-related issues that would arise/need to be added later. Hopefully the current layer is not too bloated/redundant, we can definitely trim if you think there is no need for it. I do agree it should be "disposable" ideally and removed later, so that would add some weight towards making it leaner, but at the same time it's already mostly there. Perhaps, on the other hand, would you see any extensions to it that could be needed, or is it also clear for you that only the cmap getter is needed ? If yes then I would definitely not shrink it. If no we can remove some. Let me know what you thinkl! |
|
I agree with all latest changes, thanks a lot for the testing additions |
2 participants
Scope
Adds a small compatibility layer for matplotlib, to be extended, which allows to safely transition towards more recent version and release the pin.