Add support for ~/.config/lazygit without setting XDG_CONFIG_HOME on macOS #3989
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently lazygit looks for its config file in `XDG_CONFIG_HOME` if it's available, but if not it falls back to the defaults defined by the [xdg](https://github.com/adrg/xdg) package. Unfortunately the defaults the package falls back to isn't what CLI applications commonly fall back to on macOS. Specifically, it looks in `~/Library/Application Support` instead of `~/.config`. This updates the app config logic to: - Look for `~/.config/lazygit` first if `XDG_CONFIG_HOME` is not set and we're on macOS. - Fallback to the existing `xdg` package location if the configuration file exists there. - Default to `~/.config/lazygit/config.yml` if `XDG_CONFIG_HOME` is not set, we're on macOS, and there is no existing configuration file. This change did feel a bit like having to thread a needle and I didn't see any existing tests for this behavior (which is reasonable, since it's complicated and OS dependent) so I did test a few variations of the configuration locally by building with this change included and running a `brew` installed lazygit. It seemed to work properly, falling back to the existing location when `XDG_CONFIG_HOME` isn't set, using `~/.config/lazygit` when `config.yml` is present, and creating `~/.config/lazygit/config.yml` when it's not. I think this should resolve jesseduffield#1341
|
I took a quick pass at updating the docs, but I didn't want to change too much without getting thoughts on how we might want to communicate this change, if at all. Happy to update that if you have any preferences there! |
BlakeWilliams
commented
Oct 12, 2024
| @@ -349,13 +349,34 @@ func findConfigFile(filename string) (exists bool, path string) { | |||
| return true, legacyConfigPath | |||
| } | |||
|
|
|||
| // if on macOs, default to looking in ~/.config/lazygit first since that's | |||
There was a problem hiding this comment.
I generally don't like lengthy comments in the middle of methods, but I thought that this was obtuse enough to warrant a description of why we have to implement this behavior instead of using xdg.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently lazygit looks for its config file in
XDG_CONFIG_HOMEif it's available, but if not it falls back to the defaults defined by the xdg package. Unfortunately the defaults the package falls back to isn't what CLI applications commonly fall back to on macOS. Specifically, it looks in~/Library/Application Supportinstead of~/.config.This updates the app config logic to:
~/.config/lazygitfirst ifXDG_CONFIG_HOMEis not set and we're on macOS.xdgpackage location if the configuration file exists there.~/.config/lazygit/config.ymlifXDG_CONFIG_HOMEis not set, we're on macOS, and there is no existing configuration file.This change did feel a bit like having to thread a needle and I didn't see any existing tests for this behavior (which is reasonable, since it's complicated and OS dependent) so I did test a few variations of the configuration locally by building with this change included and comparing against a
brewinstalled lazygit.It seemed to work properly, falling back to the existing location when
XDG_CONFIG_HOMEisn't set, using~/.config/lazygitwhenconfig.ymlis present, and creating~/.config/lazygit/config.ymlwhen it's not.I think this should resolve #1341
go generate ./...)