Staff dev on 1Password’s developer tools here. We screwed this up in our first few releases of the 1Password CLI, largely out of ignorance. Those releases stored config in $HOME/.op at first. But early feedback pointed us to XDG, so we migrated. Now we check:
1. $XDG_CONFIG_HOME/.op (if var is set)
2. $HOME/.config/op
3. $HOME/.op
I hate to be the dev who says “I don’t know why those other code bases find it so difficult that they put up a fight” but our `findConfigDirectory()` function isn’t exactly complicated, even when you consider all the operating systems that the 1Password CLI supports.
Congratulations, you are in the top 10% for being a professional developer, correcting mistakes and not coming up with shitty excuses.
If people from this thread took notice we all could have a clean $HOME and there would be no need for this non-discussion. As you found out, it is incredibly easy to conform to the spec.
That makes no sense. You should at most have a single directory `~/.config` more and I suppose 90% of the tools writing or reading there could be configured to use ~/.${TOOL}rc
XDG didn't (IMO) make things worse, but it also didn't help as much as it should have. My `~/.config` is the largest subdirectory of `~`, because every Chromium/Electron-based application uses `${XDG_CONFIG_HOME}/$APP_NAME/Service Worker/CacheStorage` and `${XDG_CONFIG_HOME}/$APP_NAME/Cache` (and a few other cache directories) instead of sticking those in `${XDG_CACHE_HOME}/$APP_NAME`.
Exactly. It's never getting fixed, it'd break backwards compatibility now!
It's especially frustrating because it means you can't simply back up your entire `~/.config` (or wherever you pointed your `${XDG_CONFIG_HOME}`), you have to pick specific files & folders in there.
I considered it clean when everything had a single file or directory in $HOME. Some things didn't play nice but they were the exception. Now it might be that, or there might be files scattered among one or more XDG directories.
You cannot redefine words to the opposite meaning. If you want to lump everything together then Linux is not your friend.
On Linux we separate stuff so you can for instance backup config without having to figure out for each of 100 applications where they have stored config in 100 heaps of mud.
And you are sidestepping the issue of control. With XDG you can easily and generically symlink your 100 balls of mud back with 3 lines of bash. That's because with XDG you have structure. The other way around you don´t. So don´t talk about `clean`.
> You cannot redefine words to the opposite meaning.
I'm not. Lots of things in a directory is not inherently a mess. I mentioned exceptions, things such as bash and steam make a mess because they're not completely cleanly filed away in their own directory. In my experience most things (not all) that don't use XDG are happy to cleanly files their stuff away in its own directory, sometimes divided up further into subdirectories when it makes sense. Or a single file instead of a directory if there will only be one file.
> If you want to lump everything together then Linux is not your friend.
I don't need to be friends with a kernel, and anyway, this practice has been around on Linux longer than XDG has existed. I see no reason why it won't continue to work just fine in the future.
> On Linux we separate stuff so you can for instance backup config without having to figure out for each of 100 applications where they have stored config in 100 heaps of mud.
People use Linux in different fashions. You're free to use it how you want and I'm free to use it how I want it. Your backup scheme is not suitable for me, and I suspect mine is not suitable for you. And that's OK.
> And you are sidestepping the issue of control. With XDG you can easily and generically symlink your 100 balls of mud back with 3 lines of bash. That's because with XDG you have structure. The other way around you don´t. So don´t talk about `clean`.
Most applications in my experience have a mechanism to define where configuration is read from. That's control, not your symlink mess. Structure is done appropriately per application.
It's fine if you disagree with me. It bothers me when I'm told that my opinions are wrong, which is what your post reads like to me.
And yet you impose XDG (originally a GNOME specification) on macOS (completely unrelated to GNOME or Linux). On macOS, you should be looking in ~/Library/Application\ Support/op and ~/Library/Preferences/op/config.
I’ve got a script that I’m making conform to XDG, and it's a lot of work to make it work well because I have to know about three different roots for different things (configuration, temporary files, and persistent files). I’m not convinced that it's worth it, because it is no longer as easy as telling someone "uninstall this by doing `rm -rf ~/.PROGRAM`", but instead I have to say `PROGRAM self destruct` or something like that to clean up all the detritus (and what if it fails in the middle?).
I'm pretty sure the XDG base directory spec was not specifically a gnome thing. It came from freedesktop.org[1] if I remember correctly, and in fact gnome was not compliant to begin with[2]. That gnome wiki page references that the recommendation (which turned into the spec) came from freedesktop and documents the gnome "initiative" to become compliant. Freedesktop was focussed on compatibility between desktop environments and systems, so isn't just a linux thing.
As macOS user, I'd rather they use XDG than the "standard" macOS directories. Maybe there's a point to be made to use the standard if the XDG variables aren't set, but I'd generally avoid that for CLI apps. Having everything under ~/.config is more convenient.
Agreed. "Application\ Support" looks subjectively disgusting to me. It's the only path on my configuration with spaces. I have to use it because that's where vscode settings.json is placed.
If it helps, it may have been for a good reason. Microsoft used to name the folder that stored user directories "Documents and Settings" so developers would be forced to make sure they could handle paths with spaces in them. Now, they call that folder "Users", and I had to make sure when I set up my Windows install that my name didn't have spaces in it so a bunch of apps didn't get screwy.
Big +1, macOS has a lot of UX wins, but their config directories aren't one. Also XDG allows me to have at least some things in the same place on Linux and macOS, which may be a very niche need, but still something I appreciate.
+1 to this. I have been a MacOS-exclusive user for more than a decade now and `~/Library/Application\ Support/` is simply ugly and, dare I say, un-Apple like. It has a Window's "My Documents" vibe going on.
Xdg isnt just config. Using .config (xdg config) on Mac is super weird.
Xdg is also, .cache (xdg cache dir) for data that can be cleared on reboot allowing you to use tempfs for it (of course you can't because a bunch of shit uses it as a persistent cache for things they should be putting in .local/share/. (Xdg data dir).
This whole mess is so utterly fucked I gave up caring and just let the mess be.
> Using .config (xdg config) on Mac is super weird.
Why? Using it makes macOS more similar to Linux, which I think is a good thing. It surely makes it easier to share configuration files between Macs and Linux machines.
Honestly, I don't see a single upside to using macOS's specific directories over .config/.cache/.local.
There are operating system processes in place to help keep `~/Library/Caches` smaller (or at least somewhat constrained). They are not there for `~/.cache`.
I don't see anything saying that clearing ~/.cache on every boot is expected behavior. I see lots of real world behavior of using ~/.cache as a multi-gigabyte download cache you would not want to lose regularly.
Most prsistent files should never be cleaned on uninstall, you don't know why they're uninstalling, it could just be a reinstall to fix something. Configuration might not need cleanup either.
Temporary files often shouldn't exist. If it's less that a few megabytes why is it touching disk unless it will be needed persistently? In any case the detritus doesn't matter, if it's big enough to care I'll see the disk space is low and find it with baobab at some point.
It's not perfect, but it's not a major nightmare.
For my part, I don't always follow XDG specs, I often just create ~/AppName, but sometimes I'll make more than one to keep features within one app separate. I put IP cam recordings in ~/NVR by default, and stuff like that, because the main app dir is all stuff you would backup and restore, which probably doesn't include NVR recordings for a home user.
Has a MacOS dev, I'd prefer config like this in my home directory so I can easily access it between MacOS and Linux. My expectation for CLI tools is that config is in $HOME/.config/.
Yet…that is exactly the argument of the original post. The banner argument is that VIM is wrong because it doesn’t use `~/.config/vim` and instead uses `~/.vim` … which it has used since before XDG was created. Vim also doesn’t use ~/.vim` on Windows (and the files aren't `.vimrc` and `.gvimrc`, but `_vimrc` and `_gvimrc`.
User expectations differ. The correct place to put application detritus is `~/Library` on macOS (`/Library` if it’s system-level with no user-level). I am surprised when a cross-platform library uses `~/Library` instead of XDG, but I am not unhappy with it.
Frankly, most programs should have a command like `show-config-paths` (`--show-config-paths`) so that you can see where the configuration, caches, etc. are on the platform you’re on, and possibly be told (a) whether they are overridden from default and (b) how to override them. It would be useful to have that output for both human and machine reading.
I agree 100% on having a command to this effect. I always make sure that there is a command to show the currently resolved configuration location, as well as printing out configuration (minus secrets) when the application starts in debug mode.
Furthermore, when you do '--help', whenever it's half-way reasonable, I will show you what your currently resolved settings are for any flags/variables/configs next to the corresponding flag, as well as the default value. I actually don't know why this isn't common.
Yes. I think that the plugins should probably not be in $XDG_CONFIG_HOME, but in $XDG_DATA_HOME, if I’m reading correctly.
But in part my point is that there's virtually no one who gets this correct either with Linux systems or macOS, which is what makes rants like the parent article so annoying.
1. $XDG_CONFIG_HOME/.op (if var is set) 2. $HOME/.config/op 3. $HOME/.op
I hate to be the dev who says “I don’t know why those other code bases find it so difficult that they put up a fight” but our `findConfigDirectory()` function isn’t exactly complicated, even when you consider all the operating systems that the 1Password CLI supports.
(Sorry for the formatting, I’m on my phone.)