dune icon indicating copy to clipboard operation
dune copied to clipboard

[xdg] provide macOS known directories

Open AllanBlanchard opened this issue 1 year ago • 4 comments

Fix #10398

Add ?macos:bool argument to Xdg.create. When enabled, Xdg uses known macos directories, that is:

  • ~/Library/Caches for cache,
  • ~/Application Support otherwise.

Implication of each default:

  • false: preserves current behavior but inconsistent with ?win32 default behavior,
  • true: consistent with ?win32 default, but macOS users of packages that use Xdg will potentially lose their config.

AllanBlanchard avatar Apr 11 '24 06:04 AllanBlanchard

@rgrinberg I let you decide of the default, or even whether you want to introduce the feature or not.

AllanBlanchard avatar Apr 11 '24 06:04 AllanBlanchard

While I understand the appeal of using the macOS standard directories and it might be sensible for Dune itself, it seems incorrect in the context of XDG specifically.

Quoting the specification:

$XDG_CACHE_HOME defines the base directory relative to which user-specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.

Thus if we return $HOME/Library/Caches on unset $XDG_CACHE_HOME that would violate the specification.

Leonidas-from-XIV avatar Apr 12 '24 13:04 Leonidas-from-XIV

I get @Leonidas-from-XIV 's concern, although I think the use of this library has been to map to the conventions on the operating systems. If not, you could not use the XDG library on Windows.

Maybe we could disambiguate: use a ~strict option if you need strict compliance of XDG? Of course, it would be highly inappropriate to do a strict reading of the spec on Windows, but at least if something really needs full XDG compliance they can get it.

I am really interested in the conventional macOS directories; it is 74 apps+variants in ~/Library/Application Support versus 19 in ~/.config on my machine ... and 3 of those 19 are (wrongly IMHO) influenced by the Xdg library.

jonahbeckford avatar Apr 15 '24 21:04 jonahbeckford

"strict" I think is too vague and open to interpretation. I wouldn't mind constructors for Xdg.t that interpret the spec differently. In the end, all that matters for us is how dune interacts with the spec, and not what other users of the xdg library want their programs to do. So if it's useful for them to tweak the standard for their uses, I don't see a problem with it.

rgrinberg avatar Apr 17 '24 09:04 rgrinberg