Respect XDG_* variables on macos if set

[d12bb]

When the user explicitly has set the XDG_* variables, tealdeer should use them on macOS like it does on Linux, falling back to Mac conventions if not set.

[dbrgn]

Hmm, XDG is a Freedesktop-Specification, and thus explicitly Linux-specific. Does it make sense to apply XDG-variables to macOS as well? Isn't there some kind of standard for macOS, regarding configurability of directory paths?

[d12bb]

It is, but most software coming from the Linux space does either use ~/.<tool> directly or adhere to it on macOS too, which nicely separates my config in cli tools (in~/.config) and GUI apps, which use Apple's standard (in ~/Library/Application Support I think). I don't think there is a macOS standard for user-locally overriding this other than just using XDG variables like on Linux.

[dbrgn]

We're currently using the app_dirs2 crate for determining the app directory. This library currently does not take into account XDG env vars on macOS.

Maybe you could ask there for an option to read XDG env vars on macOS as well? If that were present, we could enable it in Tealdeer (either by default, or through some kind of config option).

[dbrgn]

Anyways, since XDG variables aren't supported at the moment: You can set TEALDEER_CONFIG_DIR=/home/d12bb/.config/tealdeer/ and then create a config file at ~/.config/tealdeer/config.toml which sets the cache and pages directories: https://dbrgn.github.io/tealdeer/config_directories.html#cache_dir

The whole process is explained here: https://dbrgn.github.io/tealdeer/config.html

Does this solve your root problem?

[utkarshgupta137]

I had also done a write-up about this here: dirs-dev/directories-rs#47 (comment).
TLDR: Most non-rust CLI tools don't use ~/Library/Application Support, including the most popular like bash/zsh/fish, git, nvim, etc. And out of all the rust CLI tools I use, just from a-h, I found 7 with existing/previous issues regarding this.

[niklasmohrin]

This is a similar situation as with #320: I agree that we should move to doing the saner thing (leaving ~/Library/... behind for config, but still using it for the cache), but am not sure about how the transition should go. I think we should add a check / deprecation warning / hard error (?) about files in the old location before just totally forgetting about it, as it would otherwise be frustrating for everyone who already has config files there and got the new version from a system update or so. @dbrgn What do you think? I feel that the argumentation from the linked thread checks out and we should also use ~/.config. If Etcetera does the right thing everywhere, I am fine with changing to that too

[utkarshgupta137]

This is a similar situation as with #320: I agree that we should move to doing the saner thing (leaving ~/Library/... behind for config, but still using it for the cache), but am not sure about how the transition should go. I think we should add a check / deprecation warning / hard error (?) about files in the old location before just totally forgetting about it, as it would otherwise be frustrating for everyone who already has config files there and got the new version from a system update or so. @dbrgn What do you think? I feel that the argumentation from the linked thread checks out and we should also use ~/.config. If Etcetera does the right thing everywhere, I am fine with changing to that too

First of all, etcetera doesn't do the "right" thing everywhere. It leaves the choice up to the devs on how they want to use it. It allows you to use any convention on any platform. It is up to you to mix & match it. Do you want XDG everywhere? (some CLIs). Do you want XDG on Unix & normal Win paths on Windows? (most CLIs, few GUIs). Do you want to follow the OS-defined paths (few CLIs, most GUIs)? etcetera doesn't make the choice, you do.

So if you want XDG for config & Mac paths for cache, then you can do that. You just need to use the appropriate object. As a macOS user, I personally don't see the point of using ~/Library/Caches, because most CLIs already use ~/.cache.

Regarding transition, I can add a migration prompt or auto migration, as the maintainers prefer.

[d12bb]

As a macOS user, I personally don't see the point of using ~/Library/Caches, because most CLIs already use ~/.cache.

For caches, using Library/Caches actually is preferential, as backup tools (like Apple's own Time Machine) ignore it without needing manual configuration.

[utkarshgupta137]

As a macOS user, I personally don't see the point of using ~/Library/Caches, because most CLIs already use ~/.cache.

For caches, using Library/Caches actually is preferential, as backup tools (like Apple's own Time Machine) ignore it without needing manual configuration.

Yeah because ~/Library/Caches is usually used by GUI apps & they've large caches like browsers, chat apps, streaming services etc. On my machine ~/Library/Caches is 7.7G while ~/.cache is 93M, so I don't think it is a big deal if it is backed up or not.
Anyway, my point was that most CLI tools already use that location & it would be nice to have true XDG support on macOS too, especially if you want to move the cache directory to another disk.

[uncenter]

I also think its important to respect XDG_* variables on macOS - the user has explicitly set them. Alternatively, allow use of env vars in the directory config paths.

[niklasmohrin]

@utkarshgupta137 You already have a solid PR open for this, do you have an idea on how etcetera could be used to maintain backward compatibility (possibly only during a transition period)?

[utkarshgupta137]

You would first check the XDG folders, if tealdeer files are found, you use that. Else you check for old (current) locations, if tealdeer files are found, use them, but give the user a warning. If neither found, create new files in the XDG folders.

[niklasmohrin]

Sounds good, except for the "creating new files" part - this should only happen when using --seed-config. Do you think you can implement this behavior in #319?

[dbrgn]

Hmm, there are now two discussion topics in this thread.

Question 1: If XDG_* variables are set on macOS, should they be used?

I'm not a macOS user myself and don't know the typical conventions, but even though XDG is a Linux standard, it probably still makes sense to use XDG_* variables if they were explicitly set by the user. Thus, I'd welcome this change.

Question 2: Should the XDG-style cache directory be the default on macOS?

Here I'm not sure, and comments like this one by @d12bb indicate that there's good reason for at least some of these defaults.

I have the feeling that we should allow using XDG conventions if the variables are explicitly set by the user, but use the current defaults otherwise.

In case of the cache directory, this has the advantage that it's not being backed up by default. If we keep the cache in ~/Library/Caches, it might be strange if we use a different convention for the config directory. And finally, if we keep the current defaults, then current users without XDG_* variables don't get any breaking changes.

Thus, my suggestion would be to accept XDG_* variables, but not change the defaults.

Migration path

If we don't change the defaults, but accept the XDG_* variables, then it's still possible that we'll have users that have already set those variables. For those users, this would still be a breaking change. However, if someone explicitly sets XDG variables, those users probably have some ideas/preferences already regarding the directory paths, and will probably welcome the change.

I think it would be sufficient to print a big migration warning when:

• a page is not found, AND
• the user is on macOS AND
• XDG variables are set

This migration warning could be removed after a few releases.

Note that in most cases, this change should not interfere with auto-cache-updates because auto-updates are off by default and the config won't be found if the lookup paths change. (In theory, someone could set the XDG cache directory variable but not the config directory variable, but I think we can accept that edge case.)

What do you think, @niklasmohrin?

[uncenter]

I think you summarized the issues very well!

I have the feeling that we should allow using XDG conventions if the variables are explicitly set by the user, but use the current defaults otherwise.

Indeed, this was my thought as well. If the user sets XDG variables we should definitely respect their choices but if they don't we should put files where the OS expects them.

Thus, my suggestion would be to accept XDG_* variables, but not change the defaults.

Lovely!

This migration warning could be removed after a few releases.

That sounds like a good plan to me.

[niklasmohrin]

I think @dbrgn's comment sums up the current state of the issue. Sounds good to me, looking forward to PRs!