Live data from Hacker News

macOS dotfiles should not go in –/Library/Application Support

becca.ooo

31–40 of 223 posts

Re: macOS dotfiles should not go in –/Library/Application Support

#31

Strongly agree with the authors take. Is anyone aware of an alternative to dirs in the rust universe which follows XDG?

When I last encountered this (agreeing with the article author about the correct location for CLI tools being XDG_CONFIG_HOME), I found https://crates.io/crates/etcetera.

Re: macOS dotfiles should not go in –/Library/Application Support

#32
post #19
post #3

I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: https://codeberg.org/dirs/dirs-rs/issues/64 . It's very frustrating. I now use a combination of xdg + known-folders manually: [target.'cfg(windows)'.dependencies] known-folders = "1.2.0" [target.'cfg(not(windows))'.dependencies] xdg = "2.5.2" to get the config directory: use anyhow::{Context, Result}; #[cfg(windo…

From my previous recollection, there's an issue for this in just about every rust crate that handles these dirs. The right way to fix this is fix the spec, then make the libs adhere to the spec.

For clarity, is this what you're referring to as "the spec"? https://developer.apple.com/library/archive/documentation/Fi...

Re: macOS dotfiles should not go in –/Library/Application Support

#35
post #24
post #6

Earlier quoted context omitted.

I doubt anyone running Unix-style command-line/TUI tools where the config files are expected to be edited by hand by the user is expecting to find it in the Application Support directory; that directory is not a directory that Apple intends for users to ever interact with directly: > Put app-created support files in the Library/Application support/ directory. In general, this directory includes files that the app use…

Missing from the "hidden from the user" argument is the fact that .config, and dotfiles in general, are also hidden from the user. It's not the defining distinction that one may think it to be.

Command-line binaries are also typically installed at locations hidden from the user (/bin, /opt/homebrew, ~/.bin, ~/.cargo/bin). Further indication that the "app"-oriented Apple documentation is intended only to apply to "apps", which are installed at /Applications or ~/Applications.

Re: macOS dotfiles should not go in –/Library/Application Support

#36

The Go standard library uses ~/Library/Application Support as well [1]. Given the Unix credentials of Golang's top folks, I would assume there's a good argument in favor of this decision? [1] https://pkg.go.dev/os#UserConfigDir

UNIX, Plan 9 and Inferno, aren't exactly the same as macOS, even if macOS is a certified UNIX.

POSIX exists, because out of UNIX System V, every clone went down their own merry way.

Re: macOS dotfiles should not go in –/Library/Application Support

#37
> But suppose we accept that the XDG specification only applies to some Unix operating systems, despite making no mention of this.

the very first paragraphs on specifications.freedesktop.org says this:

> Freedesktop.org is a project to work on interoperability and shared base technology for free-software desktop environments for the X Window System (X11) and Wayland on Linux and other Unix-like operating systems. > We are not a formal standards body. The standards published on these pages are active or tentative (if marked as such) specifications which desktop environments may implement to improve mutual compatibility, share code and pool resources.

Deferring to XDG_CONFIG_HOME on MacOS if it exists makes a lot of sense as it conveys a clear intent from the user and the convention has grown popular. I’m not sure that the default ~/.config from the XDG specification is automatically better than ~/Library/Application Support by appeal to freedesktop.org’s authority.

And please don’t move configuration files around between releases without really being intentional about it.

Re: macOS dotfiles should not go in –/Library/Application Support

#38
post #3

I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: https://codeberg.org/dirs/dirs-rs/issues/64 . It's very frustrating. I now use a combination of xdg + known-folders manually: [target.'cfg(windows)'.dependencies] known-folders = "1.2.0" [target.'cfg(not(windows))'.dependencies] xdg = "2.5.2" to get the config directory: use anyhow::{Context, Result}; #[cfg(windo…

> they refuse to see it this way That's why the long-term future of app development is containers. It is not possible, on a human level, to convince people to lift even the lightest of fingers for the common good. Consider https://specifications.freedesktop.org/basedir-spec/latest/ The XDG specification has been around for 22 years. It has real benefits for users. It's trivial to implement. Yet even in the year of ou…

It's a shame that MacOS doesn't have an equivalent for Boxxy.

Re: macOS dotfiles should not go in –/Library/Application Support

#39
post #3

I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: https://codeberg.org/dirs/dirs-rs/issues/64 . It's very frustrating. I now use a combination of xdg + known-folders manually: [target.'cfg(windows)'.dependencies] known-folders = "1.2.0" [target.'cfg(not(windows))'.dependencies] xdg = "2.5.2" to get the config directory: use anyhow::{Context, Result}; #[cfg(windo…

Why is that soc guy so angry and rude about it?

I assume they've made up their mind and are now just tired of discussing it. I don't know why they refuse to even consider an option for it.

Re: macOS dotfiles should not go in –/Library/Application Support

#40
post #21
post #18

Earlier quoted context omitted.

(I maintain a fairly popular TUI library), and as a CLI/TUI user on macOS, I dislike the App Support folder a lot. But even though I dislike it, I'd expect that apps for mac should put their files there because the XDG spec doesn't apply to macOS. It's the wrong place, but the technically correct one. The right thing to do is fix the spec, and then fix the apps / libs to follow that. I wrote a top level thread that t…

How does the XDG spec not apply to macOS, and what "fix" are you proposing? https://specifications.freedesktop.org/basedir-spec/latest/ https://www.theregister.com/2024/10/11/macos_15_is_unix/ > Probably another environment variable Having any of the existing XDG_* environment variables set is an incredibly-clear indication that the user wants the XDG spec followed.

Because it was designed for Linux distros, by Linux distros, not UNIX vendors.

Where is XDG on Open Group standards?

Post reply on HN