Linux dotfiles, XDG Base Directory

[ghost]

It would be a good practice if you put all dot files from gitsome in appropriate directory based on the [XDG Base Directory specification][1]. Same goes for other operating systems, but unfortunately I'm not familiar what exactly is the best practice there.

As for Linux:

• configuration files go to $XDG_CONFIG_HOME, which defaults ~/.config/ directory
• cache files go to $XDG_CACHE_HOME, which defaults ~/.cache/ directory
• any other files go to $XDG_DATA_HOME, which defaults to ~/.local/share/ directory

[1]: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

[donnemartin]

This would tidy things up, thanks for the suggestion!

[ghost]

Unfortunately, #90 solves this issue incorrectly. Among other things, if the user doesn't have XDG_CONFIG_HOME set in their shell environment, the path expands to /<config_file_name>, which should bomb with an error because gh won't be able to write to that location (and it shouldn't write anything there).

The correct approach would define a configuration search path for each configuration <file>. The path for *nix users would be:

• $XDG_CONFIG_HOME/gitsome/<file>
• ~/.config/gitsome/<file>, assuming ~/.config exists and $XDG_CONFIG_HOME is unset
• fall back to ~/.gitsome/<file>

The technically appropriate places on Windows and OS X are, respectively, %APPDATA%\gitsome\<file> and ~/Library/Application Support/gitsome/<file> but given the nature of this app I think you can get away with just calling it ~/.gitsome/<file> (i.e. user's home directory).

One thing I do believe (and is reflected in the above pathing suggestions) is that, rather than having multiple dotfiles in the user's home directory, they should be grouped in a dotdir, i.e. .gitsome/. This lets you store whatever you need to in that directory without cluttering $HOME.

Also, I am of the opinion that if gitsome is installed in a virtual environment (i.e., $VIRTUAL_ENV or %VIRTUAL_ENV% is set), its configuration data should live in that environment. Or at least, the user should have the option to specify that configuration files outside the virtual environment can be overridden by config files the virtual environment. I may be the only one who cares about this last bit, though ¯_(ツ)_/¯.

I'd be happy to implement all of this if ya'll are interested.