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 #21

Closed
Torrencem opened this issue May 18, 2020 · 3 comments · Fixed by #41
Closed

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

Torrencem opened this issue May 18, 2020 · 3 comments · Fixed by #41
Labels
A-mac C-bug I-breaking I-needs-decision
Milestone

Comments

@Torrencem
Copy link

Torrencem commented May 18, 2020

This is roughly a migration of the issue on the old repository. To summarize:

  1. On MacOS, the library serves ~/Library/Preferences as the config directory. I consider this incorrect:
  2. Apple documentation says:

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.

  1. On the apple documentation linked in the README, it seems pretty clear that config should return ~/Library/Application Support:

Put app-created support files in the Library/Application support/ directory. In general, this directory includes files that the app uses to run but that should remain hidden from the user. This directory can also include data files, configuration files, templates and modified versions of resources loaded from the app bundle.

There was also some discussion of using ~/.config/ like on linux, as several popular CLI apps on Mac use this directory (neovim is mentioned, checking my .config I see neofetch as well). I don't think this is appropriate, since many more use ~/Library/Application Support (checking my mac, Firefox Inkscape llvmenv iTerm2 and Audacity are all examples which use it, usually with some kind of CLI)

So, I'm hoping that this can be resolved by changing the directory to ~Library/Application Support

@Torrencem
Copy link
Author

Torrencem commented May 18, 2020

Pull request is #22

@tesuji tesuji added A-mac C-bug I-breaking labels May 18, 2020
@tesuji
Copy link
Contributor

tesuji commented May 18, 2020

cc Canop/broot#103

@tesuji tesuji added the I-needs-decision label May 18, 2020
@tesuji tesuji added this to the v2 milestone May 22, 2020
@nmccarty
Copy link
Member

nmccarty commented May 26, 2020

This issue was discussed in our most recent team meeting, and we have decided that this is a bug that needs to get fixed before 2.0. We are still evaluating strategies for performing the migration, as fixing the issue would result in the undesired behavior of applications "loosing" the users config files across an upgrade, but (if possible) it will likely follow a "depreciate and swap" plan where we:

  1. Create a feature gated "correct" implementation, with opt in behavior
  2. Make an announcement about the new feature, and support both behaviors for the time being.
  3. Issue a deprecation notice for the old, broken behavior
  4. Make the new behavior the default
  5. Make the "old behavior" feature redundant by always using the new behavior
  6. Deprecate and remove the old feature

With appropriate time/version gaps between steps, this should give dependent crates plenty of time to warn their users about the migration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-mac C-bug I-breaking I-needs-decision
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants