Strongly agree with the authors take. Is anyone aware of an alternative to dirs in the rust universe which follows XDG?
macOS dotfiles should not go in –/Library/Application Support
31–40 of 223 posts
Re: macOS dotfiles should not go in –/Library/Application Support
#32I 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
#33Re: macOS dotfiles should not go in –/Library/Application Support
#34Re: macOS dotfiles should not go in –/Library/Application Support
#35Earlier 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.
Re: macOS dotfiles should not go in –/Library/Application Support
#36The 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
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
#37the 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
#38I 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…
Re: macOS dotfiles should not go in –/Library/Application Support
#39I 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?
Re: macOS dotfiles should not go in –/Library/Application Support
#40Earlier 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.
Where is XDG on Open Group standards?