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

51–60 of 223 posts

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

#51

Post by marcyb5st »

I put them in a dotfiles directory and use `stow`[1] to symlink the contents to where applications expect them to be. Under that root I have a home folder that it is symlinked to `~/`, and I have and applications one that is symlinked to `Applications Support` through the `-T` argument of stow.

To this day I still have to find anything that has problems taking a symlink instead of a file.

I am pretty happy with this setup as it means that all my dotfiles are in a single root folder that I manage through a git repo.

So I don't see what the linked articled means when it says that stows "makes (unsurprisingly) no effort to support ~/Library/Application Support.". It is literally a bit of organization from your side and passing a flag.

[1] https://www.gnu.org/software/stow/

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

#53

Post by rezonant »

JoshTriplett wrote: post #9
wpm wrote: post #5

Both options are wrong on macOS. My configurations are preferences , stored in ~/Library/Preferences. Even better if you store those as property lists and hook into CFPreferences so I can manage them with configuration profiles and use the defaults command to query and modify my preferences without having to open the app or read some 4000 line long JSONC file with 20 lines of settings and ~4000 lines of bad documenta…

To the best of my knowledge, it's incorrect to store anything other than plists in that directory. And if you're writing a cross-platform application, it's not necessarily correct to have a completely different file format on different OSes. Not all Windows applications should store all their preferences in the registry, either.

> Not all Windows applications should store all their preferences in the registry, either.

I'd honestly be fine if none of them did.

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

#54

Post by goranmoomin »

forrestthewoods wrote: post #49
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'm not writing an app, just a CLI tool but CLI tools are applications

No, they are not. Those two are very different in macOS, where the word ‘app’ means an Application Bundle, which is a directory with a .app extension, Info.plist file, a bundle identifier, have an expected directory structure per Apple guidelines, should be installed in /Applications or ~/Applications, and so on and so forth.

CLI tools, including ones that Apple ships or makes, are not apps on macOS.

I’m sorry, this is my pet peeve as well and it’s very frustrating to see this ‘CLI tools are apps’ argument from developers who are not familiar with the Apple guidelines, and then argue about on an ideological basis.

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

#55

Post by bayindirh »

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…

> That's why the long-term future of app development is containers.

That kind of "sweep under the rug" attitude is even more wrong than putting a file to wrong location. Containers are good for some stuff, but duplicating code and letting badly developed software to proliferate in its own enclave is a defeatist approach.

> I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME.

I normally use this phrase sarcastically, but this time they really deserve it. It's a skill issue, moreover, PEBKAC. If there's a standard, you SHALL obey it, esp. if you're a prominent programming language. I mean, even my small utilities obey that. But that's Microsoft...

> I've long given up on solving technical coordination problems by appealing to the universal goodness of humanity.

Thanks for the good fight, we can take the torch from here and continue the challenge. No hard feelings here.

> The only thing that works is to sandbox applications at tightly as possible

Don't be so defeatist, though.

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

#56

Post by Ferret7446 »

pasc1878 wrote: post #43
sakjur wrote: post #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. > W…

the XDG_CONFIG_HOME should point to ~/Library/Preferences. The issue is that often everyone assumes that XDG_CONFIG_HOME is ~/.config The idea of having a variable is that it could be anywhere,

XDG_CONFIG_HOME points to wherever you set it; that is up to the user to decide.

The default value, when XDG_CONFIG_HOME is not set, is by specification ~/.config. It does not (and should not) default to a different value on OSX.

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

#57

Post by padjo »

forrestthewoods wrote: post #49
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'm not writing an app, just a CLI tool but CLI tools are applications

That is covered in the article. An “App” on Mac is a specific thing with certain characteristics that CLI tools don’t have.

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

#58

Post by com2kid »

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…

I've been using macos for years, I just learned .config was a standard in this thread, because damn nearly everything shoves files in ~ so I just assumed that is where config files go.

Don't blame people for doing what 90% of apps do and assuming everyone else is correct.

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

#59

Post by thehours »

marcyb5st wrote: post #51

I put them in a dotfiles directory and use `stow`[1] to symlink the contents to where applications expect them to be. Under that root I have a home folder that it is symlinked to `~/`, and I have and applications one that is symlinked to `Applications Support` through the `-T` argument of stow. To this day I still have to find anything that has problems taking a symlink instead of a file. I am pretty happy with this…

I also use stow on MacOS and have been pretty happy with it.

> […]although macOS will regularly replace your symlinks with copies of the destination files

I’m curious about this claim from the article - to what extent is this true?

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

#60

Post by anttiharju »

dagmx wrote: post #48
x3n0ph3n3 wrote: post #46

Earlier quoted context omitted.

Certainly doesn't make me want to become a Rust contributors.

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 of the slow compile times people associate with Rust, because deserialization/serialization is kind of a common thing to do in an app.

Happy to be corrected on my statements, not 100% on anything.

edit: apparently the behaviour in Go std library is the same, heh https://news.ycombinator.com/item?id=45022680

Post reply on HN