Support `.config`/XDG configuration location in MacOSX

[briandipalma]

If both Linux and MacOSX supported the same directory for configuration it would make it easier to script machine setup. In fact some of the Rust based tools I use only support the .config directory, it'd be a rare developer who doesn't have that directory on their Mac.

[mjarkk]

I think we are not going to make the above the default because:

• The XDG library we use returns the Mac OS specific directories
• Most users already have a config file and have to do something with that.

If we would start over i think .config would indeed a better solution for a cli applications but i just don't think it's worth changing the location for x many users that already have config files.
Don't forget that we also follow the spec on windows so it's not far fetched to do the same thing on mac then and if we would default to ~/.config we should also talk about using that on windows to.

Nevertheless you should be able to set $CONFIG_DIR to configure a specific config dir but that doesn't seem to work correctly as it literally places the config files in that dir and i think we should instead place the lazygit config folder inside the $CONFIG_DIR.
I'll fix the found issue.

Have you tried setting $XDG_CONFIG_DIRS in your shell config?

[jesseduffield]

I'm cool to support this, we'd just need to find a way to make it backwards compatible. I don't really like the idea of us moving the current config files to a different directory upon lazygit being updated, but am willing to be persuaded that's actually a good move.

If we don't go ahead with a migration, we could use the following rules:

1. if the user has a .config/lazygit directory, use it
2. if the user does not have a .config/lazygit directory, but does have an XDG spec directory for lazygit, use it (i.e. existing users will stay in the old directory unless they move it themselves)
3. if the user has neither (i.e. on first installing lazygit), create the directory .config/lazygit and use that.

As @mjarkk says you can use the CONFIG_DIR env variable to set the directory as ~/config/lazygit. It was an oversight to expect /lazygit to be specified there: it certainly seems superfluous, but I don't think CONFIG_DIR is actually that common a thing in other places (based on a google search).

Lemme know your thoughts

[briandipalma]

Have you tried setting $XDG_CONFIG_DIRS in your shell config?

No, I use a variable in my Ansible scripts that is set per host:

https://github.com/briandipalma/ansible/blob/main/roles/common/tasks/lazygit.yml#L16
https://github.com/briandipalma/ansible/blob/main/group_vars/all.yml
https://github.com/briandipalma/ansible/blob/main/host_vars/Brians-MacBook-Pro.local.yml

I prefer to keep my shell config clean and lean on Ansible to deal with machine/workstation variations where possible.

This works fine but I can imagine other users may want to symlink a bunch of directories into ~/.config or may want to just copy a bunch of directories into ~/.config and so a change to support that path would be helpful for them. I raised this issue more for other/future users than myself as I've already handled the different paths.

I think the rules @jesseduffield describes make sense, personally I have to dig around/google to find the correct paths in MacOSX while I know ~/.config and can cd in there without a second thought. I'd say that's a similar story for most heavy CLI/*nix based users.

I mean ~/Library/Application Support/. That's a GUI world file path if I ever saw one.

[dehlen]

Since I am managing all my dot files with stow it would be great to be able to include the lazygit configuration here as well. Any plans on supporting the config folder next to the Application Support location?

[nadeemkhedr]

I think by now it's the default for most apps to have the config in the ~/.config directory in macos, would be great if lazygit supports that as well

[jesseduffield]

Sorry for not getting back to this thread in a while. I'm currently working on some refactoring but will happily review a PR implementing the above approach (i.e. #1341 (comment)) (using the backwards-compatible approach)

[ChrisMcD1]

/close

I believe this is closed by 59f0650