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

211–220 of 223 posts

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

#211

Post by pasc1878 »

notpushkin wrote: post #182
koakuma-chan wrote: post #86

Earlier quoted context omitted.

Can't you just std::env::var it? Why need a library? It's not even set on my MacBook though.

Yeah, the variable is usually unset, so you’ll want to have a default value in your code. Basically something like config_dir="${XDG_CONFIG_HOME:-$HOME/.config}/my-app" Of course, if you decide to account for Windows / macOS conventions, it’ll be a bit trickier, but pulling in a library for that is a bit overkill, yeah.

Adding a library for that is not overkill but just being polite to your users setting files where the OS suggests and not putting your ideas there,

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

#212

Post by Hendrikto »

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…

> 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() […] Can you even compile against both libraries if one is a fork of the other (namespace issues)?

You are really making this more complicated than it needs to be. Just do it yourself, to be honest. It’s like 3–5 lines of code. Introducing a library just complicates it.

> copy the files, delete the old dir, them and then read from the new one. […] What if copying fails mid-way?

As I said: You don’t need to copy, delete, or move any files. Just support both modern and legacy paths, and let the user take care of the migration, if they choose to.

> What if it's a symlink?

Again, why are you making this so complicated? Just try to read the file. If it fails, check the next location.

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

#213

Post by qyckudnefDi5 »

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

I'm curious if you make your home directory immutable, where do you store your files like pdfs etc?

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

#214

Post by notpushkin »

pasc1878 wrote: post #211
notpushkin wrote: post #182

Earlier quoted context omitted.

Yeah, the variable is usually unset, so you’ll want to have a default value in your code. Basically something like config_dir="${XDG_CONFIG_HOME:-$HOME/.config}/my-app" Of course, if you decide to account for Windows / macOS conventions, it’ll be a bit trickier, but pulling in a library for that is a bit overkill, yeah.

Adding a library for that is not overkill but just being polite to your users setting files where the OS suggests and not putting your ideas there,

Adding a library has nothing to do with that. You can implement it yourself in a few lines of code, especially if you only need one path, like configs. You do need to research for caveats (e.g. check $XDG_CONFIG_HOME on Linux and not just put it into ~/.config) but it’s not rocket science.

And if you choose to just trust library authors, you are putting their ideas there instead. There’s that Rust crate that uses XDG on macOS, for example.

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

#215

Post by SAI_Peregrinus »

joshka wrote: post #153
re wrote: post #32

Earlier quoted context omitted.

For clarity, is this what you're referring to as "the spec"? https://developer.apple.com/library/archive/documentation/Fi...

No the xdg base directories spec. If you want to be able to opt in to dry on a system which doesn’t canonically use xdg vars, then you need some config.

XDG is cross-distribution for Linux, but it's not cross-platform. MacOS doesn't use XDG.

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

#216

Post by johnisgood »

johnisgood wrote: post #94
anttiharju wrote: post #60

Earlier quoted context omitted.

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.

Oh yes... I am building Zed.

  Building [=>                      ] 154/1473
Amazing, 1473 dependencies!

Why is this normalized?

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

#217

Post by johnisgood »

johnisgood wrote: post #216
johnisgood wrote: post #94

Earlier quoted context omitted.

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

Oh yes... I am building Zed. Building [=> ] 154/1473 Amazing, 1473 dependencies! Why is this normalized?

1968 dependencies when building with --release. :|

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

#218

Post by sharts »

rollcat wrote: post #114
pie_flavor wrote: post #102

None of the tools the author mentions as following XDG, actually follow XDG. No default tools shipped with macOS place files under .config or anything like that. There is a bunch of dotfile vomit in $HOME and that's it. Every tool that uses .config is one you manually install from an external source. The XDG spec is to coordinate the userspace of Linux software , meaning both CLI apps and windowed apps. Linux needs t…

> [...] Linus has not bothered to write them down himself [...] He's a kernel hacker and a technical leader. He doesn't write specs for the userspace, that's the least of his concerns. Linux has very strong guarantees on syscall backwards compat - Go doesn't even use libc. This is all by design. Even the name "GNU/Linux" was something FSF tried to impose on distributions. The distributions being distributions, were f…

As a “BSD” even MacOS seems to be the odd one unlike the others.

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

#219

Post by nickm12 »

llimllib wrote: post #118
nickm12 wrote: post #66

Put me in the disagree camp. The XDG spec seems like it is for X windowing-based systems, not the Mac, so that's not a reason to adopt. The author asserts what users expect, but without any evidence. FWIW, it's not what I expect. I used Linux and Solaris extensively between 1995-2005 or so and have been a terminal using Mac user since Mac OS X public beta. My expectation is honestly that CLI programs will do whatever…

I expect _applications_ to put their config there, as the author says; something that lives in /Applications or ~/Applications and has a bundle specifier. I wish I expected CLI programs to put their config in ~/.config, but I do actually expect them to just dump them into ~ annoyingly

We have different expectations I guess. I think of CLI as applications, even though they aren't "Mac Apps". I don't see what is gained applications putting their files in different places based on how I interact with them.

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

#220

Post by joshka »

SAI_Peregrinus wrote: post #215
joshka wrote: post #153

Earlier quoted context omitted.

No the xdg base directories spec. If you want to be able to opt in to dry on a system which doesn’t canonically use xdg vars, then you need some config.

XDG is cross-distribution for Linux, but it's not cross-platform. MacOS doesn't use XDG.

That’s my point. MacOS doesn’t use it, but many expect it to do so, so make this explicitly opt in so that a user’s preference is respected over the canonical configuration. To do that the best place to define the setting is in the spec.
Post reply on HN