Overhaul Configuration

[profclems]

Currently, glab uses .env configuration format to store its configuration. Global config files are stored at the user's home directory as $HOME/.glab-cli/config/.env whereas local config files are stored in the current working directory and added to the .gitignore file to ignore it.
This solution seems not to be ideal enough as there will be several local config files spread across different folders or working directories. (This point stands to be corrected or argued on)

Solutions
An ideal solution will be to create a single user configuration file in the user's home directory that allows multiple configurations format for all working directories. Below is a solution in git config style.

[global]
         GITLAB_TOKEN=xxxxxx
         GITLAB_URI=https://gitlab.com
         GIT_REMOTE_URL_VAR=origin

[local "namespace/repo"]
         GITLAB_URI=https://gitlab.example.com

[local "namespace/repo2"]
         GITLAB_TOKEN=xxxxxx
         GIT_REMOTE_URL_VAR=origin-test

glab's configuration was done to support repos with multiple remotes, assuming the GitLab's remote nickname may not always be origin. Taking that into consideration, the above solution looks good.

However, to make the configuration simpler, YAML can also be considered. glab takes inspiration from gh, a GitHub CLI tool. gh uses YAML for its configuration and it seems to work much better with viper.
I would like to completely redo this for v2.0.0.

Configuration in YAML would be:

gitlab.com:
       token: xxxxx

gitlab.example.com:
       token: xyxyyx
remote-nickname: origin
remote-nicknames:
       namespace/repo:  origin-test

I would like to know your suggestions on the configuration file format best suited for this.
We can also consider doing it in a backward-compatible way, if possible.

[BreD1810]

I think it would be a good idea to make this change. Personally, I would prefer the YAML approach.

Backwards compatibility would be nice if possible. We should be able to check if the old local file exists, update the global one before deleting the old. Maybe a user prompt here would be a good idea.

[profclems]

I think it would be a good idea to make this change. Personally, I would prefer the YAML approach.

Yeah, same here. I prefer the YAML approach, it looks neat and has better support with viper.

Backwards compatibility would be nice if possible. We should be able to check if the old local file exists, update the global one before deleting the old. Maybe a user prompt here would be a good idea.

I thought of this solution too. This should help prevent re-configuration.

[profclems]

I should add that glab, out of the box, supports multiple GitLab providers.
The configurations are read first from the OS environment variables, then look in the current directory for a config before looking for the global one: OS ENV -> local .env config -> global .env config

I'm thinking we should maintain this style but switch configuration to YAML approach:
OS ENV -> local config.yml -> global config.yml

[zemzale]

It would be nice if this tool would respect the XDG_Base_Directory spec aka ability to place configs in ~/.config directory and not clutter my home directory.

This can be opened up as a separate issue and added to the v1 release too.

[profclems]

Thanks @zemzale, that will be considered. Please open it as a separate issue

[andhe]

FWIW my opinion is that YAML looks easy and nice at first glance but once you get to know the format you also learn about how completely insane it is. If you really want to switch format to something more formal and complex I'd suggest you instead look at TOML.

[profclems]

I think the flow with which glab read from config variables should changed. Should be
local config -> global .env config -> OS ENV
instead of
OS ENV -> local config -> global .env config
To avoid conflicting with environmental variables that are not intended for glab's use.
What are your thoughts??

@andhe @BreD1810

[BreD1810]

Personally I like the current approach as it means I can override local/global settings with environment variables should I need to. I can't think of many uses for it, but it is a nice override option that is less permanent than changing a settings file.

As for conflicting environment variables, are there any programs we know that conflict?

[andhe]

I would personally expect environment setting to override config files.