Skip to content
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

Open
AllanBlanchard opened this issue Apr 5, 2024 · 5 comments · May be fixed by #10413
Open

Xdg support: directories used for macOS #10398

AllanBlanchard opened this issue Apr 5, 2024 · 5 comments · May be fixed by #10413
Labels

Comments

@AllanBlanchard
Copy link

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
Copy link
Member

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
Copy link
Collaborator

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
Copy link
Author

AllanBlanchard commented Apr 8, 2024

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
Copy link
Member

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
Copy link
Collaborator

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.

@AllanBlanchard AllanBlanchard linked a pull request Apr 11, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants