-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Xdg support: directories used for macOS #10398
Comments
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 ? |
I don't know if this is right. All other CLI tools I've had to configure on macOS use 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 |
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 (
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
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 🤔 |
I do in fact have command line apps that write preferences to |
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. |
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
(asdata_dir
) ->~/.local/share
XDG_CONFIG_HOME
(asconfig_dir
) ->~/.config
XDG_CACHE_HOME
(ascache_dir
) ->~/.cache
XDG_STATE_HOME
(asstate_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
(asdata_dir
) ->~/Library/Application Support
(W: LocalAppData)XDG_CONFIG_HOME
(asconfig_dir
) ->~/Library/Application Support
(W: LocalAppData)XDG_CACHE_HOME
(ascache_dir
) ->~/Library/Application Support
(W: LocalAppData)XDG_STATE_HOME
(asstate_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.The text was updated successfully, but these errors were encountered: