implement a more flexible configuration mechanism than tauruscustomsettings
(I am creating this issue because even though this has been discussed many times I could not find an open issue about it)
the current problem
Currently Taurus customization is mostly done via the taurus.tauruscustomsettings
module (apart from plugin entry points).
The problem with this is that it is an install-level configuration:
- doing permanent customizations requires write access to the install dir
- customizations are lost on reinstallations
- users-level & run-level customizations are not possible
Also, the mechanism is completely taurus-specific.
the ideal goal
It would be nice to refactor taurus to make use of a mechanism with at least the following characteristics:
- support multiple level configuration (system, user, run, ...)
- based on some "standard" solution
- being OS agnostic (or at least supported by currently supported platforms)
- being supported by packaging systems (or at least compatible with conda, pypi, deb, rpm, ...)
- allowing us to wrap the access to the configs in a python module so that we can provide backwards-compatibility via
taurus.tauruscustomsettings
- if it introduces new dependencies, these should be lightweight and available in pip, conda, debian, ...
possible solutions
I did a bit of research and I feel I must be missing something obvious because I expected to find a lot of solutions and I actually found none that fills all the requirements out of the box.
Actually, the closest has been, to my surprise, Qt's QSettings, but I would discard it because it forces the pyqt dependency which now is optional for taurus.core
Other than this, the other solutions that I found were focused on parsing, but do not provide mechanisms for abstracting the access to the different locations of config files in the various OSs (requirements 1+3)
Therefore, if no better "out-of-the-box" solution is found, I think that the best is to just use the standard configparser for parsing and implement the OS abstraction and file precedence on our own, probably using pyxdg for linux and Mac and looking at the equivalent locations for win
(but as I said, I expected this to be a fairly common requirement and I am surprised at not finding an existing standard solution)