directories-rs: Config dir on macOS should not be ~/Library/Preferences

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.

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.

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.

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.

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.

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).

~/.config is 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.

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.

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 😦

@squarism That line is the data dir. Look one line up, the config dir is Library/Preferences.