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

131–140 of 223 posts

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

#131

Post by systoll »

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".

What does making a different choice for GUI and CLI apps achieve, other than making it impossible to ever have a single coherent place to look/synchronise/etc?

XDG's spec doesn't make such a distinction, so you’re advocating for a new competing standard.

I don't think Apple’s documentation intends to cover command line programs, but… in the absence of any concrete rule, putting your files where most programs on the system do is a reasonable choice, and that place will never be ~/.config/ on macOS.

Apps like homebrew that default to the library but support XDG_CONFIG_HOME if explicitly set, are a decent compromise, though.

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

#132

Post by smcleod »

delta_p_delta_x wrote: post #125
ndegruchy wrote: post #120

I disagree with this. macOS isn't Linux, and as much as I _absolutely support_ the XDG BaseDir spec, I don't think it's fair to try and apply it to macOS. Linux has no 'proper' directory for storing configuration, cache and application user data. macOS and Windows _do_. It's only proper to support those systems in the way that they intend. I wouldn't put stuff in to `%HOME%\.config` on Windows any more than I would p…

> I wouldn't put stuff in to `%HOME%\.config` on Windows Haha, and yet so many (usually Linux-first) applications do. Here's `gci $env:USERPROFILE -Force` on my computer: d---- 3/6/2022 04:39 .android d---- 6/9/2024 18:14 .cache d---- 31/7/2025 11:10 .claude d---- 16/8/2024 01:38 .config d---- 2/3/2022 07:25 .dlv d---- 7/8/2025 18:20 .dotnet d---- 19/7/2022 07:15 .eclipse d---- 1/4/2022 16:29 .fop d---- 12/10/2024 23…

Had a chuckle at "classic Linux-first development", it's every OS except Windows - Windows is the outlier here, and I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem. So I guess in the same way that roads are "classic wheel-first infrastructure", you don't try to pave a swamp.

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

#133

Post by blueflow »

delta_p_delta_x wrote: post #125
ndegruchy wrote: post #120

I disagree with this. macOS isn't Linux, and as much as I _absolutely support_ the XDG BaseDir spec, I don't think it's fair to try and apply it to macOS. Linux has no 'proper' directory for storing configuration, cache and application user data. macOS and Windows _do_. It's only proper to support those systems in the way that they intend. I wouldn't put stuff in to `%HOME%\.config` on Windows any more than I would p…

> I wouldn't put stuff in to `%HOME%\.config` on Windows Haha, and yet so many (usually Linux-first) applications do. Here's `gci $env:USERPROFILE -Force` on my computer: d---- 3/6/2022 04:39 .android d---- 6/9/2024 18:14 .cache d---- 31/7/2025 11:10 .claude d---- 16/8/2024 01:38 .config d---- 2/3/2022 07:25 .dlv d---- 7/8/2025 18:20 .dotnet d---- 19/7/2022 07:15 .eclipse d---- 1/4/2022 16:29 .fop d---- 12/10/2024 23…

Are you playing runescape at work? Or developing at home?

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

#134

Post by Aurornis »

anttiharju wrote: post #60
dagmx wrote: post #48

Earlier quoted context omitted.

dirs is a library project not part of Rust the language’s stdlib. You’ll find just as surly responses in many libraries across many languages. It feels a bit absurd to judge the language ecosystem by the maintainer of a single library.

I've also been eyeing Rust, but coming from Go where you can build more or less complete cli tools with just the standard library I'm not overtly exited by occurrences like this. From what I've seen Rust projects seem more or less node-esque in the sense that people just keep pulling all kinds of dependencies, not necessarily even understanding them that much. Like apparently serde the library is responsible for most…

If you’re allergic to external dependencies then one of the batteries-included languages is better for you.

In practice, there are a lot of well known and well maintained Rust crates for core functionality. It has also inspired some good competition among different crates to serve different purposes, such as the different command line arg parsing libraries.

I don’t find it to be a problem at all, but I know some people get triggered when they install a package and see it download different dependencies.

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

#135

Post by colejohnson66 »

codazoda wrote: post #127
ndegruchy wrote: post #120

I disagree with this. macOS isn't Linux, and as much as I _absolutely support_ the XDG BaseDir spec, I don't think it's fair to try and apply it to macOS. Linux has no 'proper' directory for storing configuration, cache and application user data. macOS and Windows _do_. It's only proper to support those systems in the way that they intend. I wouldn't put stuff in to `%HOME%\.config` on Windows any more than I would p…

I kinda wonder if this is an age thing as the English language morphs over time. I'm a bit old school, I like the XDG standard, but the arguments against "~/Library/Application Support" don't make sense to me. The people arguing against it are saying that a program that uses the CLI is not an "App". That argument seems wrong. App is short for "application" and I've been using the long form of that term since before t…

It's even in the name: a command line application. The disconnect comes from Apple adopting the term "app" when they launched the App Store in 2008. And the aggressive marketing campaign with phrases like "there's an app for that". The word changed (in some minds) from meaning "any executable" to one that is on a phone.

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

#136

Post by olddustytrail »

str4d wrote: post #104
quotemstr wrote: post #13

Earlier quoted context omitted.

> 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…

> The XDG specification has been around for 22 years. Indeed! > It has real benefits for users. I once believed this! > It's trivial to implement. Nope! I ranted about this a while back ( https://bsky.app/profile/str4d.xyz/post/3lsjbnpsbh22i ) but the tl;dr is that the XDG specification is imprecisely written and internally inconsistent, and there has been confusion since at least as early as 2003 about what kind of…

The spec says

"There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME"

Where are you seeing "read-only"?

And why would it not be safe? What kind of user specific documentation did you think should go there and even if you did, why would you think it could be randomly removed by something else?

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

#137

Post by Aurornis »

notachatbot123 wrote: post #87
bowsamic wrote: post #22

Earlier quoted context omitted.

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

Imagine having built some software, abiding to a standard that to your understanding is the standard to abide to. Then comes people who ask you to break that standard and change your software. Again and again they come. Others ridicule your stance on social media and forums like these. It's burning out. It's free and open-source for heaven's sake! If you don't like it, fork it, patch it, make your own custom version.…

> But stop pestering maintainers with demands.

I don’t see any “pestering” in the linked issues. They’re polite and well-written with supporting links.

This is how it’s supposed to be done. Suggestions for improvements or issues noticed go into issue requests for discussion. If the maintainer doesn’t want to do it, a polite and concise explanation is typical.

The refrain of “just fork it!” is a cop-out. Forking software so you can maintain a fork forever isn’t a trivial decision. It’s not helpful to the community to have to choose between a lot of different forks that have minor differences.

I agree that open source maintainers don’t owe anyone anything, but I think this mentality is being taken too far when with the “maintainer is always right” mentality combined with blaming the issue starter for the maintainer’s behavior.

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

#138

Post by ndegruchy »

delta_p_delta_x wrote: post #125
ndegruchy wrote: post #120

I disagree with this. macOS isn't Linux, and as much as I _absolutely support_ the XDG BaseDir spec, I don't think it's fair to try and apply it to macOS. Linux has no 'proper' directory for storing configuration, cache and application user data. macOS and Windows _do_. It's only proper to support those systems in the way that they intend. I wouldn't put stuff in to `%HOME%\.config` on Windows any more than I would p…

> I wouldn't put stuff in to `%HOME%\.config` on Windows Haha, and yet so many (usually Linux-first) applications do. Here's `gci $env:USERPROFILE -Force` on my computer: d---- 3/6/2022 04:39 .android d---- 6/9/2024 18:14 .cache d---- 31/7/2025 11:10 .claude d---- 16/8/2024 01:38 .config d---- 2/3/2022 07:25 .dlv d---- 7/8/2025 18:20 .dotnet d---- 19/7/2022 07:15 .eclipse d---- 1/4/2022 16:29 .fop d---- 12/10/2024 23…

Oh, I'm well aware of this on Windows. It's stupid and easy enough to fix for the developer, but I'm also aware there is virtually no desire to implement.

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

#139

Post by delta_p_delta_x »

smcleod wrote: post #132
delta_p_delta_x wrote: post #125

Earlier quoted context omitted.

> I wouldn't put stuff in to `%HOME%\.config` on Windows Haha, and yet so many (usually Linux-first) applications do. Here's `gci $env:USERPROFILE -Force` on my computer: d---- 3/6/2022 04:39 .android d---- 6/9/2024 18:14 .cache d---- 31/7/2025 11:10 .claude d---- 16/8/2024 01:38 .config d---- 2/3/2022 07:25 .dlv d---- 7/8/2025 18:20 .dotnet d---- 19/7/2022 07:15 .eclipse d---- 1/4/2022 16:29 .fop d---- 12/10/2024 23…

Had a chuckle at "classic Linux-first development", it's every OS except Windows - Windows is the outlier here, and I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem. So I guess in the same way that roads are "classic wheel-first infrastructure", you don't try to pave a swamp.

> Windows is the outlier here

What about Android? The only thing Android shares with Linux is the kernel; the entire user mode environment is completely different, and this includes how 'users' and their data are handled. What about automotive stuff like VxWorks?

> I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem.

Good for you; then why even bother releasing stuff for Windows? Because it checks the 'here's your Windows release, now bugger off' box? As a parent commenter says,

> it is because they thought 'with -target darwin I don't get any compilation errors. ship it!'

What happened to actually caring about users, their expectations, and user-friendliness, without worrying about platform dogmas?

As an aside, Windows has the objectively superior filesystem permissions model. It supports a massive variety of access modes, uses ACLs by default, and this is what allows straightforward fleet management with AD. It is easier to map down Windows ACLs to POSIX octal file permissions than to map up the reverse.

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

#140

Post by BenjiWiebe »

franga2000 wrote: post #129
Hendrikto wrote: post #100

Earlier quoted context omitted.

This has been a solved problem forever. It is very simple, very easy, very short, extremely maintainable code. When writing the files, check the old location first, fall back to the new one. When reading, check check the new location first, fall back to the old one. The app does not need to migrate anything. Using the algorithm described above, new installations will automatically use the new paths, old installations…

But how do you find the old location? Do you need to build against both libraries, call old_lib.get_path(), check if it exists, then call new_lib.get_path(), copy the files, delete the old dir, them and then read from the new one. What if it's a symlink? What if copying fails mid-way? Does the library or the program handle all of this? Can you even compile against both libraries if one is a fork of the other (namespa…

The app doesn't migrate the files, so no worrying about copying. Don't bother even checking if it's a symlink. A symlink is a file. Just open it and read it.
Post reply on HN