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

71–80 of 223 posts

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

#71

Post by hoherd »

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'
or in Windows:

    >>> user_config_dir(appname, appauthor)
    'C:\\Users\\trentm\\AppData\\Local\\Acme\\SuperApp'
https://pypi.org/project/platformdirs

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

#72

Post by SulphurCrested »

varenc wrote: post #64
SulphurCrested wrote: post #47

Towards the end TFA claims that Apple’s bundled command line utilities, including zsh and vim, put their dotfiles in ~/.config. They don’t. They put them in the traditional BSD place, the user’s home directory ~/. Looking at mine now, I see .bash_login, .emacs (wow! that’s old), .lldb, .lldbinit, .vimrc, .swiftpm, .z{profile,env,rc} and a few others. I see no ~/.config directory. My personal practice when writing com…

> My personal practice when writing command line utiities for macOS is to use the macOS API to write settings (previously known as “preferences”) into ~/Library/Preferences This would mean that essentially all edits to the configuration must be performed by the CLI tool itself? Because macOS preferences aren't really intended to be edited directly by the user. That feels like a totally different category of configura…

Yes, ideally the tool should edit its own preferences. A quick and dirty tool might leave the user to run the macOS "defaults" command line utility themselves. It’s certainly no worse than looking up the dotfile format and firing up vi.

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

#73

Post by Someone »

I agree with “should not go in ~/Library/Application Support”, but why would anybody put them there? The Mac way is ~/Library/Preferences, or, system-wide /Library/Preferences, and the use of NSDefaults.

https://developer.apple.com/library/archive/documentation/Fi...:

“This directory contains app-specific preference files. You should not create files in this directory yourself. Instead, use the NSUserDefaults class or CFPreferences API to get and set preference values for your app. In iOS, the contents of this directory are backed up by iTunes and iCloud.”

If a tool doesn’t want to use NSDefaults, using ~/.config is way preferable over polluting the user’s home directory, as many tools do.

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

#74

Post by soraminazuki »

blueflow wrote: post #41

Follow the link to the XDG spec, look who is the 3rd author. There is no reason for MacOS or the BSDs to implement a systemd spec. A specific example: XDG_RUNTIME_DIR is a feature of pam_systemd and nothing else. This is a recurring pattern that systemd documentation is sold as "neutral" standard. The UAPI group is another example of this.

3rd author? Wow, I respect the effort you went through to find that one connection to systemd, however faint it may be.

Also, XDG_RUNTIME_DIR is a just a directory. Since when did directories become a systemd feature?

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

#75

Post by [deleted] »

soraminazuki wrote: post #74
blueflow wrote: post #41

Follow the link to the XDG spec, look who is the 3rd author. There is no reason for MacOS or the BSDs to implement a systemd spec. A specific example: XDG_RUNTIME_DIR is a feature of pam_systemd and nothing else. This is a recurring pattern that systemd documentation is sold as "neutral" standard. The UAPI group is another example of this.

3rd author ? Wow, I respect the effort you went through to find that one connection to systemd, however faint it may be. Also, XDG_RUNTIME_DIR is a just a directory. Since when did directories become a systemd feature?

[deleted]

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

#76

Post by soni96pl »

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…

From the same person: https://soc.me/standards/defending-home

I'm aware it mentions Linux specifically, but this is golden:

> From this point on, the number of dot-files and dot-directories can only shrink as the remaining applications get fixed and start conforming to the XDG base directory spec, while no new dot-files and dot-directories can be added to your home directory.

As is original reasoning for not using ~/.config from https://github.com/dirs-dev/directories-rs/issues/62#issueco...

> As Apple keeps tightening its after-sale ownership of macOS appliances, it's becoming increasingly unlikely that randomly dumping stuff in $HOME will keep working.

I get the feel he just does not like macOS?

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

#77

Post by swiftcoder »

SulphurCrested wrote: post #72
varenc wrote: post #64

Earlier quoted context omitted.

> My personal practice when writing command line utiities for macOS is to use the macOS API to write settings (previously known as “preferences”) into ~/Library/Preferences This would mean that essentially all edits to the configuration must be performed by the CLI tool itself? Because macOS preferences aren't really intended to be edited directly by the user. That feels like a totally different category of configura…

Yes, ideally the tool should edit its own preferences. A quick and dirty tool might leave the user to run the macOS "defaults" command line utility themselves. It’s certainly no worse than looking up the dotfile format and firing up vi.

> It’s certainly no worse than looking up the dotfile format and firing up vi

It's a lot worse, IMO. We're all fluent in our text editor of choice, we all know the rough format conventions of dot files.

Whereas I'd certainly have to lookup man page of the defaults tool, and IIRC it only supports editing one-key-at-a-time, which sucks for a dense config file.

If your tool provides a TUI/GUI for editing preferences, that'd be a different story.

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

#78

Post by blueflow »

soraminazuki wrote: post #74
blueflow wrote: post #41

Follow the link to the XDG spec, look who is the 3rd author. There is no reason for MacOS or the BSDs to implement a systemd spec. A specific example: XDG_RUNTIME_DIR is a feature of pam_systemd and nothing else. This is a recurring pattern that systemd documentation is sold as "neutral" standard. The UAPI group is another example of this.

3rd author ? Wow, I respect the effort you went through to find that one connection to systemd, however faint it may be. Also, XDG_RUNTIME_DIR is a just a directory. Since when did directories become a systemd feature?

[flagged]

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

#79

Post by trissylegs »

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…

It doesn't have very large standard library. It's just running on a different philosophy on not making the Standard Library "Batteries included". But I find you get less dependencies than npm. Not so many tiny left-pad like microlibraries.

The main cost of compile times is Generics. Rust generics use "Monomorphization" which generate different binary code for every use of a generic type.

serde leverages generics everywhere and it generates the serialization code for every type you make serializable. So when you use `serde_json::to_string(MyType::new())` it follows calls a code path just for serializing MyType to a json string.

The upshot: It's incredibly fast, there's a lot of inlining and other compiler optimisations that can used because of it. No runtime reflection (Which is how Go does a lot of it).

The downsides: Takes a long time to compile cause of all the extra it's generating. Also can inflate binary sizes at bit.

Other languages like Go mostly use run time reflection for Json. Rust doesn't have much runtime reflection so doing it here wouldn't be possible

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

#80

Post by tyilo »

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…

It seems like `etcetera` has better defaults: https://docs.rs/etcetera/latest/etcetera/#native-strategy

> `choose_base_strategy()` and `choose_app_strategy()` will use the XDG strategy on Linux & macOS, and the Windows strategy on Windows. This is used by most CLI tools & some GUI tools on each platform.

Post reply on HN