Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Config dir on macOS should not be ~/Library/Preferences #62

Closed
lilyball opened this issue Jan 9, 2020 · 18 comments
Closed

Config dir on macOS should not be ~/Library/Preferences #62

lilyball opened this issue Jan 9, 2020 · 18 comments

Comments

@lilyball
Copy link

lilyball commented Jan 9, 2020

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

@lilyball
Copy link
Author

lilyball commented Jan 9, 2020

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.

@squarism
Copy link

squarism commented Jan 9, 2020

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.

@lilyball
Copy link
Author

lilyball commented Jan 9, 2020

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.

@squarism
Copy link

squarism commented Jan 9, 2020

@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

@lilyball
Copy link
Author

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

@emilazy
Copy link

emilazy commented Feb 16, 2020

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 :(

@justinmk
Copy link

justinmk commented Feb 16, 2020

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

@soc
Copy link
Collaborator

soc commented Feb 16, 2020

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.

@emilazy
Copy link

emilazy commented Feb 16, 2020

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.

@soc
Copy link
Collaborator

soc commented Feb 16, 2020

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.

@emilazy
Copy link

emilazy commented Feb 16, 2020

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.

@lilyball
Copy link
Author

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.

@emilazy
Copy link

emilazy commented Feb 21, 2020

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.

@soc
Copy link
Collaborator

soc commented Feb 21, 2020

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

@Canop
Copy link

Canop commented Feb 21, 2020

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 ?

@soc
Copy link
Collaborator

soc commented Mar 9, 2020

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

@DarrienG
Copy link

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.

@soc
Copy link
Collaborator

soc commented Jun 21, 2020

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.

Sharparam added a commit to Sharparam/facti that referenced this issue Aug 19, 2023
The directories crate doesn't use XDG on macOS, which is apparently
the preferred way for CLI apps to store configuration.

See:
dirs-dev/directories-rs#47
dirs-dev/directories-rs#62
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants