Config dir on macOS should not be ~/Library/Preferences
lilyball opened this issue · 18 comments
This library is vending ~/Library/Preferences as the config dir on macOS. This is a bad idea. Apple's own documentation explicitly states
You should not create files in this directory yourself. Instead, use the
NSUserDefaultsclass or CFPreferences API to get and set preference values for your app.
Any configuration files written by the app without using one of those two APIs belongs in ~/Library/Application Support instead.
When this fix is made, there will also need to be some API that provides access to the old path, so tools can use it to migrate data to the correct location.
What about using XDG style paths instead or in addition to? Or having an option to do so? ~/.config is not unusual for CLI apps on mac.
I agree that XDG-style paths are preferable for CLI apps, though there would need to be some way to get the desired macOS-style paths for GUI apps.
@lilyball Maybe only the docs are wrong?
This seems to imply that it's already doing what you want. I'm using a binary that uses this lib on mac and it does put it under Application Support/.
https://github.com/soc/directories-rs/blob/master/src/mac.rs#L13
@squarism That line is the data dir. Look one line up, the config dir is Library/Preferences.
This is probably more a bug in dirs-rs than this library per se, but I'd also like to see this fixed; I'd like to adopt directories-rs rather than rolling my own code, but not at the expense of polluting the wrong directories in the process of trying to respect platform conventions :(
~/.configis not unusual for CLI apps on mac.
fwiw, that was the rationale for choosing ~/.config as the macOS XDG default in Neovim.
As a user, the hiearchy of ~/Library seems pretty random to me, whereas ~/.config/<app> is obvious. Not to mention choosing ~/.config for all unix-like OSes (including macOS) seems intuitive.
As Apple keeps tightening its after-sale ownership of macOS appliances, it's becoming increasingly unlikely that randomly dumping stuff in $HOME will keep working.
I'm not going to sign up to build stuff that guarantees that people will come running my way when things break a few years down the road, because my lib happens to show up last in their stacktrace.
You should not create files in this directory yourself. Instead, use the NSUserDefaults class or CFPreferences API to get and set preference values for your app.
Any configuration files written by the app without using one of those two APIs belongs in ~/Library/Application Support instead.
Alternatively simply do what Apple tells you to do and use NSUserDefaults/CFPreferences. Their computers, their rules.
Switching to the XDG directories would be a major change – though I personally think it's extremely unlikely that you're ever going to be unable to write to dotfiles in $HOME – but Apple's guidelines explicitly say that Application Support should be used over Preferences for application-generated configuration files and that programs should never manually create files in the latter, so IMO it's clear that dirs-rs should be returning the former.
You should not create files in this directory yourself. Instead, use the NSUserDefaults class or CFPreferences API to get and set preference values for your app.
Apple's guidelines explicitly say that Application Support should be used over Preferences for application-generated configuration files and that programs should never manually create files in the latter [...]
Alternatively simply do what Apple tells you to do and use NSUserDefaults/CFPreferences. Their computers, their rules.
I'm confused... Doesn't the argument of "As Apple keeps tightening its after-sale ownership of macOS appliances, it's becoming increasingly unlikely that randomly dumping stuff in $HOME will keep working." apply even stronger to ~/Library/Preferences? They explicitly tell you not to create your own files there, so I wouldn't be surprised if that stops working at some point.
Their rules explicitly say it's okay to put your own configuration files in Application Support:
For example, you might use this directory to store app-created data files, configuration files, …
and I don't see anything mandating the use of NSUserDefaults/CFPreferences for application configuration data, so I really don't understand your objection to making this change.
Apple is tightening up system stuff, including the root volume, but the only restrictions they've placed on what a user can do in their own home folder is adding explicit permissions to accessing certain sensitive data (such as contacts database). There's no motivation for them to prevent users from creating dotfiles and I would be shocked if they ever did it.
As for NSUserDefaults / CFPreferences, if you want to use those then use those. That's not related to directories-rs though. Those aren't APIs for storing arbitrary configuration, they're APIs for a specific key-value preferences store.
I'm not going to sign up to build stuff that guarantees that people will come running my way when things break a few years down the road, because my lib happens to show up last in their stacktrace.
Stuffing arbitrary stuff into ~/Library/Preferences is pretty much the only behavior being discussed that has any chance of breaking a few years down the road, because locking down that folder to just cfprefsd is pretty much the only applicable restriction I could see Apple implementing. Using ~/Library/Application Support is what we should be doing if we're using Apple's folder structure (and will always be supported), and using XDG is what we probably should actually be doing for cross-platform CLI apps because that's the unix way, and both approaches can be expected to be supported for the indefinite future.
Is this bug effectively WONTFIX?
If so, could the incorrect behaviour at least be documented and the issue closed? I'm not sure what the point of a platform directories library advertising support for macOS is if it's not going to use the correct platform-specific directories.
Not WONTFIX; but WORKS AS INTENDED if I don't come up with a bright idea on how to resolve this in a way that doesn't introduce incorrectness.
Letting multiple things point to the same folder brings up the same problems as on Windows (https://github.com/soc/directories-rs/blob/master/src/win.rs#L65), where cache/config/data postfixes are added defensively to safe "smart" developers from themselves and shouldn't be done lightly (nor retroactively).
As I understand the issue, it's neither WONTFIX, nor WORKS AS INTENDED, it's still an attempt at specifying the best behavior.
Should the API introduce an optional context to precise things such as cli_application ?
Should the API introduce an optional context to precise things such as cli_application ?
I think there are already crates out there that do that (this crate won't).
FWIW I have a user that is interested in the same sort of thing: https://gitlab.com/ttyperacer/terminal-typeracer/-/issues/29
I know what's going on right now is technically the right behavior, but I figured it was worth voicing too.
Thanks to all for your persistence!
Version 3 of both dirs and directories shipped with the proposed change to config_dir on macOS, as well as the addition of preference_dir that retains the old behavior and allows accessing Library/Preferences for cases where this may still be required.