The worst offenders are CLI tools written by people on Macs that do not respect XDG, because it's not a thing over there. So every tool gets to pollute your dotfiles with its own stupid directory. .rustup, .mix, .npm, .yarn, etc.
But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive.
Weirdly, enough, golang is one of the only programming languages that actually has built-in support for a cross-OS config dir location: [os.UserConfigDir()][1].
I don't really ever program in golang, but whenever I write a Node.JS/Python tool that does need a user-global config file, I just write my own implementation of it:
function userConfigDir() {
switch (process.platform) {
case 'darwin':
return `${os.homedir()}/Library/Application Support`;
case 'win32':
if (process.env['APPDATA']) {
return process.env['APPDATA'];
} else {
throw new Error('%APPDATA% is not set correctly');
}
case 'aix':
case 'freebsd':
case 'openbsd':
case 'sunos':
case 'linux':
return process.env['XDG_CONFIG_HOME'] || `${os.homedir()}/.config`;
default:
throw new Error(`The platform ${process.platform} is currently unsupported.`);
}
}
>But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive.
Counterpoint:
I actually like having visible directories, versus having to figure out where in /usr/share or /usr/local/ or ~/.local or /var an installer chose to sneak their files in.
I got used to it and in HOME I put some of my manually installed tools like `AMD_AOCL` for the AMD AOCL libraries, `Android/android-studio` for Android Studio, `intel` for IPP/OpenAPI, etc.
Don't want it anymore? Easy rm -rf, no need to go digging for where it could be hidden.
"I actually like having visible directories, versus having to figure out where in /usr/share or /usr/local/ or ~/.local or /var an installer chose to sneak their files in."
You seem to be mixing together two concepts here:
1. The files created by the installer, which are handled by the package manager. I can consult my package manager for files created by a specific package: pacman -Ql package_name.
2. The files created after installation (user preferences, plugins). The program should follow the XDG specification.
And those should be avoided as much as possible because they're always problematic and break randomly. How could they not break, when the package manager doesn't even know they exist or what they depend on?
In theory, all applications following XDG would also solve the problem, as it has only 1 configuration directory. (Although I admit some apps use the data directory which brings it up to 2)
> XDG is not a thing on Windows either afaik. Is a convention on one operating system something other operating systems should be faulted for not following?
GP is saying they should follow XDG on Linux not do it anywhere else!
Though if you're a CLI app on OS X, maybe consider it (especially if XDG_CONFIG_HOME _is_ defined), seems more common than the native OS X location for this type of app.
I guess the ire towards macOS-created apps comes from the fact that you can write macOS things that work on Linux without doing the “proper” things for the platform.
Windows is SO different that you have to do real porting work.
When something requires a minimal amount of porting effort to do 100% perfectly, or zero effort to do 99% it seems a lot of apps go for that 99%.
For my part writing cross platform apps I never actually realized there was a standard for arranging dotfiles so I wouldn’t have even realized I was leaving something out. XDG was one of those things I was vaguely aware existed and figured had something to do with the house of cards that is Linux desktop environments.
But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive.