Bug: guidata writes its configuration to `~/.config/.none/none.ini`

[StefanoPierini-Codra]

Component: guidata.config / guidata.userconfig
Affected version: 3.15.0 and, as far as can be told, every earlier version
Severity: low to medium — settings are stored under a meaningless name, in a directory shared with any other unnamed UserConfig

Symptom

Importing guidata creates ~/.config/.none/ (Windows: %USERPROFILE%\.none\), and guidata's own settings are persisted to ~/.config/.none/none.ini, with sections:

[faulthandler] [arrayeditor] [dicteditor] [texteditor] [codeeditor] [console] [color_schemes]

Expected location would be something like ~/.config/.guidata/guidata.ini.

Root cause

guidata/config.py:

CONF = UserConfig(DEFAULTS)

UserConfig.__init__ sets self.name = "none" as a placeholder, and set_application() is never called on this instance. Since UserConfig.get_path() builds ~/.config/.{self.name}/… and filename() returns {self.name}.ini, everything ends up in .none/none.ini.

Two aggravating factors:

• get_path() has a side effect: it calls os.makedirs on the directory. The stray directory is therefore created even by a read-only path lookup, e.g. when guidata merely checks whether a file exists.
• The .none directory is a shared namespace: any library that forgets to call set_application resolves to the same directory, and to the same none.ini filename. Two such libraries saving in the same process would overwrite each other's file, since ConfigParser.write() rewrites the whole file from the sections the instance knows about. PlotPy currently falls in this category (it never names its CONF), though it happens not to call CONF.save(), so no collision is observed today.

[PierreRaybaut]

Thanks for the detailed report. I agree that the underlying issue is valid, with one nuance regarding the reported symptom.

UserConfig is intentionally initialized in two steps: code creating its own UserConfig instance is expected to call set_application() before using persistence-related operations. In that sense, "none" is a placeholder rather than an intended application name.

However, this is more problematic for the module-level CONF instances provided and used internally by guidata and PlotPy. Requiring every application using guidata to know about and initialize those internal singletons would be a fragile and currently undocumented contract. The basic guidata example, for instance, does not call set_application().

I also tested this with a temporary home directory on the current 3.15.1 sources:

• import guidata and import guidata.config alone did not create .none;
• calling guidata.config.CONF.filename() created .none;
• calling CONF.set(...) then created .none/none.ini;
• importing plotpy.mathutils.colormap created .none, because that module calls CONF.get_path() during import.

So I would slightly narrow the symptom: a bare guidata import does not appear to create the directory by itself, but any code path calling get_path(), filename(), or saving an unnamed configuration does.

I would classify this as a low-severity configuration/API bug: caller-created UserConfig instances should still require set_application(), but built-in CONF instances should either be initialized by their owning package, or path/persistence operations should fail clearly while the configuration is unnamed instead of silently using the shared .none namespace. Avoiding directory creation during read-only path lookup would also be worth considering.