Xdg support: directories used for macOS

[AllanBlanchard]

Currently, XDG uses the same behavior for macOS and other Unix-like operating system. However, if one refers to the Apple Guidelines on directories organization, this should not be the case.

Xdg provides (I excluded home and runtime dir which are not important here):

• XDG_DATA_HOME (as data_dir) -> ~/.local/share
• XDG_CONFIG_HOME (as config_dir) -> ~/.config
• XDG_CACHE_HOME (as cache_dir) -> ~/.cache
• XDG_STATE_HOME (as state_dir) -> ~/.local/state

The macOS hierarchy is quite different and in fact, it is closer to the behavior that is currently implemented for Windows. As far as I understand the XDG standard and the Apple Documentation, we should have:

• XDG_DATA_HOME (as data_dir) -> ~/Library/Application Support (W: LocalAppData)
• XDG_CONFIG_HOME (as config_dir) -> ~/Library/Application Support (W: LocalAppData)
• XDG_CACHE_HOME (as cache_dir) -> ~/Library/Application Support (W: LocalAppData)
• XDG_STATE_HOME (as state_dir) -> ~/Library/Caches (W: InternetCache)

The main problem is that fixing this would basically break packages that use XDG. On the other side, it would improve compatibility with macOS tools (for example, automatic backups on macOS ignore ~/Library/Caches). Also, I am wondering what is the best way to detect that we use macOS.

[rgrinberg]

If I'm getting this right, this is about choosing different defaults for the various XDG paths on MacOS. I suppose there's nothing wrong with that. I'd like to hear the opinion of other mac users. @anmonteiro @samoht ?

[anmonteiro]

I don't know if this is right. All other CLI tools I've had to configure on macOS use ~/.config too, and I've never had to reach for anything in ~/Library.

Putting aside what the defaults should be, isn't the point of having an XDG implementation that you can set those environment variables in your system and the xdg library will use them correctly? Or is your issue specifically about what defaults Dune should choose?

[AllanBlanchard]

I am not a mac user. The reason why I looked at it is that I have to use some of these directories, and I do not want to pollute users Home if I can avoid that (typically for caches). But I am really interested in what happens when the XDG variables are not positioned.

The reason why I find all of this confusing is that most libraries (dune-xdg included) in fact provide:

• an API with named directories,
• that first tries to load XDG environment variables,
• and fallback on OS specific directories when they are not available.

The last item seems to be the one on which people tend to disagree. For Linux, the consensus is clear, on Windows almost (modulo history, directories have slightly changed along the years), on macOS, not much.

At first, I was tempted to just implement that myself (since it is quite simple), so I looked at how people implemented this in different languages (Java: https://github.com/dirs-dev/directories-jvm, Go: https://github.com/adrg/xdg, OCaml: https://github.com/ocamlpro/directories, Rust: https://lib.rs/crates/dirs) and it seems that people try to respect OS conventions but it is not systematic, I found a bunch of libraries that are perfectly Unix centric (strictly implementing Xdg) and other that use alternative for Windows only.

The reason why I ask the question for dune-xdg is that since I already depend on this library via other packages, I could just use it, without introducing a new dependency, but I was pretty surprised to see that it just uses the home directory like it is done on Linux despite the existence of a specific hierarchy in the OS documentation.

All other CLI tools I've had to configure on macOS use ~/.config too, and I've never had to reach for anything in ~/Library.

The tool I work on is not (only) CLI, but I am not sure that it should be different for CLI tools and non-CLI tools 🤔

[rgrinberg]

I do in fact have command line apps that write preferences to ~/Library/Application Support. lazygit is one example that comes to mind. If changing the default on macos is controversial, we could always add a separate constructor for Xdg.t that uses these defaults for MacOS.

[anmonteiro]

I do in fact have command line apps that write preferences to ~/Library/Application Support.

OK I don't have a strong opinion if there are in fact applications that use those directories. I was just trying to understand the issue since I haven't used those directories before in my projects.

[teezett]

Setting different XDG variables to the same folder ~/Library/Application Support breaks the intention of XDG to separate these files in different folders and treat them separately.

For example the configuration in XDG_CONFIG_HOME should be saved in a git repo with gnu stow or nix home manager. The files in XDG_DATA_HOME shall be included in backup, while state and cache files are excluded from backup.
For that purpose different directories are needed.

So my approach to this is trying to enable XDG conformity for as many apps as possible.
I use xdg-ninja for help to do this.
For some it is necessary to move the files to the correct places and replace them by links at the old location.
Some like vscode don't have any ordered structure of their files, so I just ignore them.
And some are conform to Mac File Structure - so I leave them in that way.