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

91–100 of 223 posts

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

#91

Post by johnisgood »

watersb wrote: post #88

XDG directories for macOS dotfiles is my hill to tilt windmills. To make it extra fun, my $HOME directory is immutable: chflags uchg "${HOME}" (Simply setting it read-only would work too.) Preventing arbitrary writes in $HOME breaks things, but it's actually quite rare. I should document this setup. Or perhaps it's better to keep the madness to myself...

No, I think you should write more about it. Motivations, what about programs or scripts that require writing or at least modifying files in $HOME, etc.? You say it is rare, but is it really? Also what is your way when you want to communicate between two programs? What is your preferred method of IPC? I will check how much my system works if I do the same thing as you, on Linux. :D

FWIW I use firejail so applications cannot run anything in $HOME and temporarily (heh) mounted tmpfs (two separate options).

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

#93

Post by franga2000 »

kstenerud wrote: post #68
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…

Sounds like it's time to make a fork of dirs-rs that actually follows the rules. Most libraries that use dirs-rs are doing so because they don't want to have to think about those things. So if there were a library that did it right, you'd probably have decent adoption if it's a simple crate replacement.

Where do I store my files is never a simple replacement. At the very least you need to write a migration routine and maintain it for a very long time.

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

#94

Post by johnisgood »

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…

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

My experiences as well. Try to "cargo build" any projects, and you will immediately see the node-esque problems. It does not fill me with hope.

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

#95

Post by OJFord »

varenc wrote: post #62
pdpi wrote: post #29

If your binary is supposed to live in `/Applications`, by all means put its config in `~/Application Support`. If it lives in `/bin` or somewhere similar, or if its default or system-wide configuration go in `/etc`, config goes in `~/.config`.

Agreed! but mostly moot. As a general rule, CLI utilities which are just single binaries should not go in /Applications. That folder is for app bundles which are folders with a .app extension, an Info.plist file, etc. And its not on the PATH used in the shell (by default). I think the exception is app bundles which also include some sort of auxiliary CLI utility that usually gets symlinked from its location in the /A…

It's not moot though, because this whole thing is about the CLI binaries (usually because of a decision made by a framework like dirs-rs) using 'Application Support' et al.

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

#96

Post by dwattttt »

sebws wrote: post #89
cedws wrote: post #52

XDG is a Linux-centric spec. If we the people want it to be OS-agnostic, it needs to be vetted and designed for that. Until then I don’t see why macOS applications must adopt XDG, despite it being my preference.

from the article, > Elsewhere, Reilly Wood rebukes a user asking if there would “be any downside to just not using Application Support ever” by saying that “[Nushell would] no longer be following the macOS Standard Directories guidelines.” > We’ll read through those guidelines in a minute, but it’s not entirely clear to me that they’re relevant in the first place. The XDG Base Directory Specification mentions Unix a…

> The XDG Base Directory Specification mentions Unix a few times but lists no carveouts for macOS or any other operating system.

I could write a specification that says where files should go on macOS, and I could even get people to agree with me. That doesn't mean macOS or anyone else needs to care what we think

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

#97

Post by OJFord »

joshka wrote: post #18
re wrote: 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…

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

> this should be fixed by adding an explicit "I want XDG even though I'm on macOS" setting somewhere. Probably another environment variable.

Why another one? If an XDG env var is set explicitly, that's obviously what the user wants. Just don't (necessarily) use the spec's defaults when it's not set.

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

#98

Post by dkmar »

watersb wrote: post #88

XDG directories for macOS dotfiles is my hill to tilt windmills. To make it extra fun, my $HOME directory is immutable: chflags uchg "${HOME}" (Simply setting it read-only would work too.) Preventing arbitrary writes in $HOME breaks things, but it's actually quite rare. I should document this setup. Or perhaps it's better to keep the madness to myself...

honestly as long as they don’t use the home directory ill survive. vscode and similar apps not offering any alternative to home directory pollution kills me.

I assume this breaks vscode? Would love a writeup if you have time

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

#99

Post by [deleted] »

re wrote: post #32
joshka wrote: post #19

Earlier quoted context omitted.

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

[deleted]

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

#100

Post by Hendrikto »

franga2000 wrote: post #93
kstenerud wrote: post #68

Earlier quoted context omitted.

Sounds like it's time to make a fork of dirs-rs that actually follows the rules. Most libraries that use dirs-rs are doing so because they don't want to have to think about those things. So if there were a library that did it right, you'd probably have decent adoption if it's a simple crate replacement.

Where do I store my files is never a simple replacement. At the very least you need to write a migration routine and maintain it for a very long time.

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 will continue using the old paths, but can optionally be migrated at the user’s convenience.

Post reply on HN