Use XDG_CONFIG_HOME path instead of home directory

[aronmolnar]

The CLI tool reptor populates the user's home directory by storing the config files in ~/.sysretpor. This can be fixed by adding support for the XDG Base Directory and storing the config file in $XDG_CONFIG_HOME/sysreptor/config.yml.

It is, however, only applicable if XDG variable is set and must also work on Windows environments (even though an alternative directory could be used there too, like Roaming).

There are, additionally, some complexities how to handle existing config files.

[noraj]

It is, however, only applicable if XDG variable is set

The env. var. don't necessarily have to be set as XDG has default values for them. E.g. $XDG_DATA_HOME defaults to $HOME/.local/share. So generally, XDG env. var. are sets only when the default value is overwritten.

must also work on Windows environments

XDG Base Directory doesn't exist for Windows (it's only for Unix systems), but what does some libraries is to map those change the default values of then env. var. to map them to windows paths e.g. https://stackoverflow.com/questions/43853548/xdg-basedir-directories-for-windows.

[aronmolnar]

Thanks @noraj for your input.

What makes things complex is that we need to find the configuration files if...

• XDG is empty/not set (e.g., in environments where this variable doesn't exist; default to home)
• If it is set, and before it wasn't (move the config from home to xdg? probably not)
• If it was set, but no it isn't any longer (there is probably no solution for this)

[noraj]

What mature softwares do is to define, several locations possible with a priority, e.g.

1. $XDG_CONFIG_HOME/sysretpor/config.yml (to respect XDG, user config has proprity)
2. ~/.config/sysretpor/config.yml (if $XDG_CONFIG_HOME was set to something else but the config file is not there for some reason, it cover the case where the config file was deployed to default XDG location before a custom $XDG_CONFIG_HOME value was set on the system)
3. $XDG_CONFIG_DIRS/sysretpor/config.yml (to respect XDG, system config)
4. /etc/xdg/sysretpor/config.yml (if $XDG_CONFIG_DIRS was set to something else but the config file is not there for some reason, it cover the case where the config file was deployed to default XDG location before a custom $XDG_CONFIG_DIRS value was set on the system)
5. /etc/sysretpor/config.yml Optionally, for legacy mind reflex.
6. /usr/share/sysretpor/config.yml Optionally, if a default config file is provided on a system package.
7. ~/.sysretpor/config.yml for retro-compatibility
8. If no config file was found, create one at $XDG_CONFIG_HOME/sysretpor/config.ymlAlgorithm is has follow: While no config file found, loop over possibles paths. Specifically, for path candidates that contains a XDG env. var., instead of directly reading `$XDG_CONFIG_HOME env. var. for example, read it with a XDG library so if the env. var. is not set, it will return the default XDG value instead. Default XDG values would also be part of your path candidates list to cover the case where there was no XDG before and there is now.

Also before doing the loop, check if there is an override with:

1. a --config CLI flag
2. a SYSREPTOR_CONFIG env. var.

With this all cases are covered. XDG not set? check XDG default. Migration to the new system? Legacy path is covered. Config location moved? The fallback mechanism covers all common cases. For the point you mentioned:

• XDG is empty/not set (e.g., in environments where this variable doesn't exist; default to home)
  • The XDG lib fallback to default XDG value if env. var. not set, the loop over all candidates handle the case where XDG env. var is empty or invalid
• If it is set, and before it wasn't (move the config from home to xdg? probably not)
  • No need to move the file, the loop covers all possible locations. default XDG value in path candidates also covers edge case where the config file was deployed to default XDG location before a custom $XDG_CONFIG_DIRS value was set on the system
• If it was set, but no it isn't any longer (there is probably no solution for this)
  • It the env var was set and is not longer, but the value was the default one then it's ok as it's in the loop. If it was a custom value and now the env var is unset, then there is no solution to guess the custom path. But you can fix that in several ways: A system package can deploy a default config file at /etc/xdg/sysretpor/config.yml, /etc/sysretpor/config.yml or /usr/share/sysretpor/config.yml so that if $XDG_CONFIG_HOME that was pointing to a custom /specialmountpoint/mysoftwares/sysretpor/config.yml, the loop will fallback on a default system config. Linux distro can also deploy specifically cooked configs that way. And then on last instance, if the loop is exited without a config file was found, then create one with default values.

[noraj]

On this website you'll find: https://xdgbasedirectoryspecification.com/

• Code examples in python & go
• "What if I already do the wrong thing and use the home folder directly?" but we covered it above
• "Who else does this?" to go see implementations in other sofwtares
• What to do on MacOS and Windows for crossplatformness