feat!: use os.UserConfigDir() if $GNO_HOME not set

[grepsuzette]

Description

In #652 Moul talked about supporting *nix stardard XDG variables.
I'm also a fan of this.

Propose going for $XDG_CONFIG_HOME.
So the order would become:

1. $GNO_HOME
2. $XDG_CONFIG_HOME/gno (usually this variable is $HOME/.config)
3. .gno in the home directory

Fixes #655

How has this been tested?

I just introduced a panic:

if hd != "" {
        panic(fmt.Sprintf("%s/gno", hd))
        return fmt.Sprintf("%s/gno", hd)
    }

and it returned /home/bob/.config/gno

[thehowl]

#655 - let's use os.UserConfigDir instead of XDG_CONFIG_HOME?

[moul]

I also prefer os.UserConfigDir over raw $XDG_.

[grepsuzette]

Yes makes sense.

Tested with the same method
and it returned /home/bob/.config/gno when $GNO_HOME not set.

[thehowl]

Some comments.

One note for you - your PR will likely be merged after #585. Seeing as that's ready, we're trying to merge as few crucial and small things as possible in order to avoid endlessly solving merge conflictts on that branch - although merging it will probably create a conflict on this one.

[thehowl]

I was looking through the go source, and it looks like the behaviour on non-windows is always a Getenv("HOME") for both UserConfigDir and UserHomeDir. Which means that realistically the result of the function is either hd + "/gno" or a panic. I think we can change this so that

hd, err = ...
if err != nil // panic
return filepath.Join(hd, "gno")

also, change variable name to cd? (h doesn't make sense anymore)

[grepsuzette]

they don't use xdg? why did they make an API in that case 🙄
ok I will look that up. Thanks for the notice!

Edit: but no, I tested it, it returns /home/bob/.config/gno. Or you meant Windows instead of non-windows?

[grepsuzette]

I took a look the doc https://docs.studygolang.com/pkg/os/#UserConfigDir
but it seems ok to me:

func UserConfigDir() (string, error)

UserConfigDir returns the default root directory to use for user-specific configuration data. Users should create their own application-specific subdirectory within this one and use that.

On Unix systems, it returns $XDG_CONFIG_HOME as specified by https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html if non-empty, else $HOME/.config. On Darwin, it returns $HOME/Library/Application Support. On Windows, it returns %AppData%. On Plan 9, it returns $home/lib.

If the location cannot be determined (for example, $HOME is not defined), then it will return an error.

And

func UserHomeDir 1.12

func UserHomeDir() (string, error)

UserHomeDir returns the current user's home directory.

On Unix, including macOS, it returns the $HOME environment variable. On Windows, it returns %USERPROFILE%. On Plan 9, it returns the $home environment variable.

[thehowl]

This is more of an addendum to what we were saying on #655, but while @moul said that we don't need to ensure backwards compatibility, because in this case we're changing the behaviour of gnokey where the keys are stored (so something literally everyone who has tinkered with the project will have done), I think it makes sense here to add steps to transition things properly.

I think we can either:

1. Implicitly move ~/.gno to join(configDir, "gno")
2. Show a warning if we can stat ~/.gno without an error like: The default value for --home / GNO_HOME has been changed to <newConfigDir>, and you still have a directory in <homeDir>/.gno . We suggest to either set in your environment GNO_HOME to <homeDir>/.gno, or move it to the new directory.

(I'm much more of a fan of the first -- if we want to be transparent, adding a log message saying we've moved the dirs)

[grepsuzette]

This is more of an addendum to what we were saying on #655, but while @moul said that we don't need to ensure backwards compatibility, because in this case we're changing the behaviour of gnokey where the keys are stored (so something literally everyone who has tinkered with the project will have done), I think it makes sense here to add steps to transition things properly.

I think we can either:

1. Implicitly move `~/.gno` to `join(configDir, "gno")`

2. Show a warning if we can stat `~/.gno` without an error like: `The default value for --home / GNO_HOME has been changed to <newConfigDir>, and you still have a directory in <homeDir>/.gno . We suggest to either set in your environment GNO_HOME to <homeDir>/.gno, or move it to the new directory`.

(I'm much more of a fan of the first -- if we want to be transparent, adding a log message saying we've moved the dirs)

I don't think we should move a hidden directory such as ~/.gno somewhere else.
There is nothing to add here in my opinion, not even a message.
Complicating the TUI UX for no reason, and introducing potential bugs, while people may have backup procedures already in place for ~/.gno is not a good idea.

Because remember, it will just continue to work for existing users ($HOME/.gno being the last resort fallback).

[grepsuzette]

(Regarding my comment about filepath, I took a look at the usages of it through the repo.
It's probably better to keep using it for consistency, as there are many other usages of filepath besides the separator thing.)

[grepsuzette]

Some comments.

One note for you - your PR will likely be merged after #585. Seeing as that's ready, we're trying to merge as few crucial and small things as possible in order to avoid endlessly solving merge conflictts on that branch - although merging it will probably create a conflict on this one.

Thanks for the note.
It's fine if there's a conflict, it will help me familiarize with the new repo structure :)

[grepsuzette]

@thehowl I tried but think I can not solve the conflict without losing the git blame info. So I will open a new PR, closing this one.