Component: plotpy.config / plotpy.mathutils.colormap
Affected version: 2.11.0 and, as far as can be told, every earlier version
Severity: medium — user-created colormaps are written to a bogus directory, and never follow the host application's configuration directory
Symptom
- Custom colormaps created by the user are saved to
~/.config/.none/colormaps_custom.json (Windows: %USERPROFILE%\.none\colormaps_custom.json), not to a PlotPy-owned directory.
- A stray
~/.config/.none/ directory is created merely by importing PlotPy, even when the user never saves anything.
- When a host application claims a configuration directory via
CONF.set_application("MyApp_v1/plotpy", …), the INI file moves but the colormaps do not: they keep pointing at .none.
Root cause
Two independent defects combine.
1. PlotPy never names its own UserConfig
plotpy/config.py:
CONF = UserConfig(DEFAULTS)
guidata.userconfig.UserConfig.__init__ sets self.name = "none", and get_path() resolves — and creates, via os.makedirs — ~/.config/.{self.name}/…. Without a set_application() call the name stays "none", so every path derived from CONF lands in ~/.config/.none/.
2. Colormap paths are resolved at import time and never refreshed
plotpy/mathutils/colormap.py computes its paths as module-level constants:
DEFAULT_COLORMAPS_PATH = get_cmap_path(CONF.get("colormaps", "colormaps/default", …))
CUSTOM_COLORMAPS_PATH = get_cmap_path(CONF.get("colormaps", "colormaps/custom", …))
CUSTOM_COLORMAPS_PATH is the file PlotPy writes to (save_colormaps(CUSTOM_COLORMAPS_PATH, CUSTOM_COLORMAPS)). A host application's set_application() call necessarily happens after plotpy.mathutils.colormap has been imported, so the path is already frozen. This is why symptom 3 affects host applications such as DataLab even though they do claim a configuration directory.
Note that PlotPy never calls CONF.save(), so no PlotPy settings are actually stored in .none/none.ini — that file belongs to guidata (see the companion issue). Only the colormaps are at stake.
Component:
plotpy.config/plotpy.mathutils.colormapAffected version: 2.11.0 and, as far as can be told, every earlier version
Severity: medium — user-created colormaps are written to a bogus directory, and never follow the host application's configuration directory
Symptom
~/.config/.none/colormaps_custom.json(Windows:%USERPROFILE%\.none\colormaps_custom.json), not to a PlotPy-owned directory.~/.config/.none/directory is created merely by importing PlotPy, even when the user never saves anything.CONF.set_application("MyApp_v1/plotpy", …), the INI file moves but the colormaps do not: they keep pointing at.none.Root cause
Two independent defects combine.
1. PlotPy never names its own
UserConfigplotpy/config.py:guidata.userconfig.UserConfig.__init__setsself.name = "none", andget_path()resolves — and creates, viaos.makedirs—~/.config/.{self.name}/…. Without aset_application()call the name stays"none", so every path derived fromCONFlands in~/.config/.none/.2. Colormap paths are resolved at import time and never refreshed
plotpy/mathutils/colormap.pycomputes its paths as module-level constants:CUSTOM_COLORMAPS_PATHis the file PlotPy writes to (save_colormaps(CUSTOM_COLORMAPS_PATH, CUSTOM_COLORMAPS)). A host application'sset_application()call necessarily happens afterplotpy.mathutils.colormaphas been imported, so the path is already frozen. This is why symptom 3 affects host applications such as DataLab even though they do claim a configuration directory.Note that PlotPy never calls
CONF.save(), so no PlotPy settings are actually stored in.none/none.ini— that file belongs to guidata (see the companion issue). Only the colormaps are at stake.