feat: follow XDG Base Directory Specification

[mochaaP]

See https://specifications.freedesktop.org/basedir-spec/latest/.

[mochaaP]

fixes #81

[mgmacias95]

Hello!

Thank you for your contribution! :)

After discussing with the team, we think it's best to use these two functions that are included in golang's os built-in library:

• https://pkg.go.dev/os#UserHomeDir
• https://pkg.go.dev/os#UserCacheDir

More specifically, UserCacheDir should be used to store the relationships cache and UserHomeDir should be used to store the user's configuration.

Cheers,
Marta

[mochaaP]

I think you meant UserConfigDir() for the first one -- see https://cs.opensource.google/go/go/+/go1.23.4:src/os/file.go;l=528

I will apply the suggested changes.

[mochaaP]

Done via 6c02129

[mgmacias95]

Hello @mochaaP,

Thank you for such a quick response!

About your comment: I meant the home dir specifically. Right now vt-cli's configuration file is stored in the home directory. Storing it somewhere else is a breaking change that will force everyone to reconfigure their vt-cli again. In addition to that, making manual changes to the file stored in the config dir is harder since remembering the path is harder than simply accessing your home directory.

If I run ls -lah ~, I can see a lot of configuration directories for other clis I am using, not just vt's.

Cheers,
Marta

[mochaaP]

I will make viper try to find ~/.vt.toml first, then fallback to os.UserConfigDir()/vt-cli/vt.toml.

[mochaaP]

made it migrate the configuration file automatically so existing installations won't break.

imo this is better because:

1. not everyone needs to edit vt-cli's configuration frequently, so it's better to get out of users' way
2. if someone needs to switch between configuration files, switching the working directory already gets the job done
3. the dot prefix doesn't really hide the file on windows (looking at you, .dotnet)

[mgmacias95]

What about something like this?

if windows then:
   ConfigDir
else:
   HomeDir

This way windows users can benefit from this while UNIX users keep the behaviour they are used to.

[mochaaP]

I think unix users today prefer the use of ~/.config and following this convention has been popularized among many programs.

[plusvic]

I think unix users today prefer the use of ~/.config and following this convention has been popularized among many programs.

The concern is not really with Linux, but with macOS, putting the config file in $HOME/Library/Application Support is far from ideal IMHO. That would be the natural place to put configuration files for native macOS GUI apps, but for a command-line tool like this one, I believe most people will prefer the same behaviour in both Linux and macOS. Windows is a very different story, but Linux and macOS are both POSIX-compliant operating systems and have similar file system structure, both of them have the ~/.config path, and most people will expect them to behave in the same way. Many CLI tools put their configuration in the home directory, and many others in ~/.config, but $HOME/Library/Application Support is very uncommon for this kind of applications.

Regarding whether to put the config file in ~/.config or the home directory, that's a matter o preference, none of the options have a clear benefit over the other. As ~/.config is getting the most popular option, I would chose it over the home directory for new tools, but honestly, I wouldn't change it for existing tools just for the sake of it. In my opinion consistency is more important here. Once users get accustomed to some way of doing things, they don't want changes.

I like the idea of getting rid of homedir package (which seems to be unmaintained) and moving the relationships cache to path returned by UserCacheDir. But for the config file I would use the path returned by UserHomeDir. That's a good tradeoff that introduces support for the XDG_ environment variables, without disturbing existing users too much.

[jovial-snyder]

Regarding whether to put the config file in ~/.config or the home directory, that's a matter o preference, none of the options have a clear benefit over the other.

I beg to differ (from a Linux user perspective). I think applications that don't use use the XDG specs are developed by devs who don't know that such a thing exists. There are multiple reasons to use it, some of which are explained here https://xdgbasedirectoryspecification.com

[plusvic]

Regarding whether to put the config file in ~/.config or the home directory, that's a matter o preference, none of the options have a clear benefit over the other.

I beg to differ (from a Linux user perspective). I think applications that don't use use the XDG specs are developed by devs who don't know that such a thing exists. There are multiple reasons to use it, some of which are explained here https://xdgbasedirectoryspecification.com

Indeed, I take responsibility for not adhering to the XDG specifications when this tool was implemented. At the time, I was unaware of the XDG standards, and it was only after this issue was raised that I became familiar with them. That said, I do recognize the advantages of following these specifications. I fully support incorporating the XDG_ environment variables and even agree with relocating the configuration file to ~/.config.

However, what I strongly oppose is having the configuration file stored in different locations on Linux and macOS. As I mentioned earlier, $HOME/Library/Application Support is likely the most appropriate location for configuration files in native macOS applications. But for a cross-platform CLI application, I believe it’s better to maintain consistency by storing the configuration file in the same path on both Linux and macOS.