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

151–160 of 223 posts

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

#151

Post by bsimpson »

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…

Before they rebased onto UNIX, Mac files had two parts: a data fork and a resource fork. Data had the binary. Resource had strings, images, and other assets that the binary needed.

It was great for local portability: you could put the file wherever you wanted, and it would still be colocated with its stuff. It was bad for network portability, because a lot of transport layers didn't respect the forks.

So Apple migrated to bundles - magic folders that look like a single file in the Finder, but contain all the resources it might need.

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

#152

Post by brewmarche »

seanyeh wrote: post #115
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…

git supports XDG - its config lives in `$XDG_CONFIG_HOME/git/config`. Though a lot of people still use the older location of ~/.gitconfig

As does vim (e.g. $XDG_CONFIG_HOME/vim/vimrc and $XDG_CONFIG_HOME/vim/pack/...)

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

#153

Post by joshka »

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

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.

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

#154

Post by joshka »

OJFord wrote: post #97
joshka wrote: post #18

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

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

The xdg vars only control the location. There’s no var to control that xdg should be used. macOS has a canonical approach, which some tools choose to ignore. I want a flag to make that ignorance correct

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

#155

Post by bowsamic »

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

I don’t think it’s unreasonable to be demanding when this refusal negatively affects a lot of other rust software

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

#156

Post by cosmic_cheese »

Unpopular opinion maybe, but even under Linux and BSDs I’ve felt that dot folders/files in home are poor practice. Hiding them was a band-aid for bringing *nixes into the GUI era and just adds an extra hurdle outside of the CLI, and many of them are overly specific compared to the other standard user folders.

I think macOS has the right idea with ~/Library/ though I’m not as sure about the name. Maybe ~/Support/ or ~/System/ or something makes more sense, but whatever the case I’d rather see the dot files/folders swept up into proper unhidden directories under that directory, e.g. ~/Support/Config/, ~/Support/SSH/, etc.

Which really is all the reason more why programs should actually check $XDG_CONFIG_HOME. It’s not good to just assume when a distro or user might have different conventions set up.

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

#157

Post by esafak »

hoherd wrote: post #71

Somewhat related, a few weeks ago on Python Bytes I learned that there is a python module that abstracts various directory locations per-platform. For instance, you can use this module to find the location of the Movies directory, or the cache directory. For example, on macOS: >>> appname = "SuperApp" >>> appauthor = "Acme" >>> user_config_dir(appname, appauthor) '/Users/trentm/Library/Application Support/SuperApp' o…

If any Windows users are interested in this, you could help fix the linked PRs that will close this issue once the Windows aspects are addressed:

https://github.com/tox-dev/platformdirs/issues/368

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

#158

Post by xyst »

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…

dirs maintainer is bit unhinge, maybe the high usage of crate has gotten to their head.

If I ever have time, I would love to fork this repository, patch it to support XDG_*, and actively work to advertise it across the rust ecosystem. If user wants to use different location on file system to store configuration files, then let them. Stop trying to dictate what users want.

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

#159

Post by SquibblesRedux »

Has the XDG Base Directory Specification been adopted by an official standards committee? In my previous life, calling something a standard carried a great deal of weight. For example, contracts could mandate compliance with standards.

Having built apps and CLI tools for macOS, the author's post certainly makes sense to me. Calling something a standard without backing from a standards committee seems odd, however.

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

#160

Post by notachatbot123 »

Aurornis wrote: post #137
notachatbot123 wrote: post #87

Earlier quoted context omitted.

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

I used pestering for OP's "I and others have brought this up (...) but they refuse to see it this way (...). It's very frustrating."

Suggest it once, discuss it, get refused, move on. Instead there are tens of comments and above is a complaint about an additional ticket for the same issue.

I am not saying that maintainers are necessarily right, but they are in their right to build their project how they like it. It is a bad pressure and force if people continue to ask for things that a maintainer has already ruled out. What's the goal otherwise, caving in due to pressure and stress?

Post reply on HN