Repository navigation
Bug: PlotPy stores custom colormaps in ~/.config/.none/ instead of its own configuration directory #70
Description
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.
Activity
PierreRaybaut commentedon Oct 29, 2026
Thanks for the report: both root causes are confirmed, and reproduced on the current
developsources (PlotPy 2.12.0.dev, guidata 3.16) with a temporary home directory.Two clarifications:
.nonedirectory is created:import plotpyandimport plotpy.configalone do not create it. It is created whenplotpy.mathutils.colormapis imported, because the module callsCONF.get_path(), which creates the directory. In practice this happens in almost every use of PlotPy, since image items, styles and tools import this module.set_application()is called. For instance, SigimaX names PlotPy's configuration"plotpy"when its options are instantiated, and DataLab later renames it"DataLab_v1/plotpy". Today's results:~/.none/colormaps_custom.jsondatalab.app)~/.plotpy/colormaps_custom.jsonimport datalab.configfirst)~/.none/colormaps_custom.jsonDataLab_v1/plotpy)Colormaps are therefore shared by accident, between applications that happen to resolve to the same directory. Even then, they are loaded only once per process, and each save rewrites the whole file, so two applications running at the same time overwrite each other's additions.
The chosen fix follows the existing intent of host applications: custom colormaps are stored per application, in the configuration directory set with
CONF.set_application(), with.plotpyas PlotPy's own default. Existing colormaps from.noneand.plotpyare copied to the new location the first time, without modifying the old files. Details in #88.Fix custom colormaps location (store them in the application config d…
docs(config): document that PlotPy's directory also stores colormaps (#…