search

app-dirs-rs / app_dirs2

A maintained fork of the app-dirs-rs project.
MIT License
35 stars 7 forks source link

[macos] Use XDG_* variables if present instead of ~/Library #36

Closed diktomat closed 1 year ago

kornelski commented 1 year ago

macOS is not a Linux distribution, and it’s incorrect to treat it as one. Cocoa has its own naming conventions and locations. XDG on macOS is a foreign spec that goes against Apple’s standards.

Would you make Linux use APPDATA instead of HOME or support CSIDL_PROGRAM_FILES when present? XDG is just as weird and alien on macOS.

diktomat commented 1 year ago

It's so against their standards that they ship software using it, like Git. Most command line utilities use either XDG_CONFIG_HOME or plain dotfiles in ~, regardless which unixoid platform they're on, so AppSupport is as alien to those as .config would be to gui programs.

kornelski commented 1 year ago

The fact that Apple bundles a 3rd party Linux-centric irreplaceable developer tool does not make macOS a freedesktop.org-compatible distribution.

macOS is a Unix only on a technicality, as much as Quebec is "America". It has POSIX compatibility, an even had a Unix certification that Apple stopped caring about after 2003, and shipped some command-line utilities that have been bitrotting since 2007. But macOS also has its classic Mac OS side mixed with NextStep, and is primarily its own Cocoa-based platform, doing things Apple's own way, often intentionally going against conventions that emerged on Linux and other *BSDs.

macOS has some Linux-like directories, but developers are discouraged from using them. They're mostly for compatibility with non-native programs ("non-native" on macOS is seen as bad). macOS uses /Users, not /home, it has ~/Library/Caches, not /var/cache and absolutely not ~/.cache.

A pan-unix approach of ignoring macOS specifics and treating it as an eye candy for a generic BSD has real annoying consequences. For example Cargo is painful with its use of ~/.cargo and ./target instead of directories designated by Apple. It causes Spotlight to index all these files for search, creating a lot of churn and slowing down compilation (Spotlight watches the whole disk in real time). It also bloats Time Machine backups with redundant files.

Even the directory structure exposed by this crate is already a stretch. The concept of dumping custom config files in some directory is not supposed to exist on macOS. There's NSUserDefaults subsystem for this, which is an API, not a directory. I know it is very different from what pan-unix tools do, but that's macOS. Apple's OS has its own different, perhaps weird and incomplete, ways of doing things. Your custom ~/config file won't work with the defaults command or the plist editor. I can't stress enough how alien and inappropriate XDG is for macOS. You shouldn't treat macOS as any more similar to Linux than Windows is (and I mean Windows proper, not WSL).

diktomat commented 1 year ago

Even the directory structure exposed by this crate is already a stretch. The concept of dumping custom config files in some directory is not supposed to exist on macOS. There's NSUserDefaults subsystem for this, which is an API, not a directory. I know it is very different from what pan-unix tools do, but that's macOS. Apple's OS has its own different, perhaps weird and incomplete, ways of doing things. Your custom ~/config file won't work with the defaults command or the plist editor.

But isn't this an argument pro using XDG_CONFIG_HOME? If ~/Library/Application Support is supposed to be used via an API, wouldn't it be better to use any other directory?

utkarshgupta137 commented 1 year ago

As pointed out by @eugenesvk in this comment, ~/Library/Application Support is the wrong location for files that are meant to be user-editable. It is hidden by default & it is only meant for App-managed files. The correct location for user-editable files is supposed to be ~/Documents/.

kornelski commented 1 year ago

Application Support is not for use via API. It's for arbitrary application-private data. I've was referring to app configuration, which on macOS uses an API, and not files directly.

utkarshgupta137 commented 1 year ago

Application Support is not for use via API. It's for arbitrary application-private data. I've was referring to app configuration, which on macOS uses an API, and not files directly.

I think you might be getting confused about app-managed vs user-managed confs. I've already added a write up about it here. TLDR: I agree that Application Support is the right place for app-managed config files, both according to apple guidelines & my personal opinion. OTOH, using it for user-managed confs goes against Apple guidelines & it is also a pain in the ass for many users.