Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

becca.ooo

Post reply on HN
Print view View original

11–20 of 223 posts

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

#11

Post by JoshTriplett »

re wrote: post #6
JoshTriplett wrote: post #2

It seems like the best of both worlds, here, would be to put the files in ~/.config/yourprogram, and symlink that to `~/Library/Application Support/org.example.yourprogram`. That would satisfy folks expecting to find it in either place. The only folks it wouldn't satisfy would be those complaining about the files being present in one of those places at all, and that seems like the least of the concerns compared to ma…

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…

> where the config files are expected to be edited by hand by the user

Many good command-line tools manage their config files automatically, in addition to allowing the user to hand-edit them. I don't think that materially changes this, though: people may still expect to find them in `~/.config`.

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

#12

Post by JoshTriplett »

CGamesPlay wrote: post #7
orlp wrote: 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…

I think there should be two crates in rust-land. The answer by @soc makes sense for apps , as the article discusses. Many (most?) people building Rust programs aren't making apps and so shouldn't be using this crate, which clearly and definitively only supports MacOS "Apps".

It sounds like https://docs.rs/etcetera/0.3.2/etcetera/index.html provides sufficient flexibility for apps that want this.

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

#13

Post by quotemstr »

orlp wrote: 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 our lord two thousand and twenty five I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME.

I've long given up on solving technical coordination problems by appealing to the universal goodness of humanity. The only thing that works is to sandbox applications at tightly as possible and direct all their access to the external world through narrow interfaces that do their best to limit shenanigans.

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

#17

Post by joshka »

I wrote elsewhere that I think the solution to this is to add another variable to the XDG Base Directory Specification to explicitly opt into using XDG variables, and then to support that flag on libraries that target Windows / MacOS and which would otherwise choose mac Application Support / Windows AppData folders.

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

#18

Post by joshka »

re wrote: post #6
JoshTriplett wrote: post #2

It seems like the best of both worlds, here, would be to put the files in ~/.config/yourprogram, and symlink that to `~/Library/Application Support/org.example.yourprogram`. That would satisfy folks expecting to find it in either place. The only folks it wouldn't satisfy would be those complaining about the files being present in one of those places at all, and that seems like the least of the concerns compared to ma…

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…

(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 this should be fixed by adding an explicit "I want XDG even though I'm on macOS" setting somewhere. Probably another environment variable.

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

#19

Post by joshka »

orlp wrote: 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.

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

#20

Post by Gigachad »

quotemstr wrote: post #13
orlp wrote: 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…

How is it even common good though? The articles main argument is that the author didn't expect the files there, not that it was causing any kind of issue. The problem is that people disagree where a config file should go, and there's no compelling reason why either of them are right or why it even matters.
Post reply on HN