Prompt for country on first run and save to config file

[rossf7]

Towards #16

On first run we now check if the config file ~/.config/grid-intensity/config.yaml exists.

If not the user is prompted to enter a country code. We still show the country from the user's locale as a hint.

go run .
Provider ember-climate.org needs an ISO country code as a region parameter.
ESP detected from your locale.
FRA
{
	"country_code_iso_2": "FR",
	"country_code_iso_3": "FRA",
	"country_or_region": "France",
	"year": 2021,
	"latest_year": 2021,
	"emissions_intensity_gco2_per_kwh": 67.781
}

Running a 2nd time the saved setting is used.

go run .
{
	"country_code_iso_2": "FR",
	"country_code_iso_3": "FRA",
	"country_or_region": "France",
	"year": 2021,
	"latest_year": 2021,
	"emissions_intensity_gco2_per_kwh": 67.781
}

Specifying a country code will save the new value.

go run . -c DE
{
	"country_code_iso_2": "DE",
	"country_code_iso_3": "DEU",
	"country_or_region": "Germany",
	"year": 2021,
	"latest_year": 2021,
	"emissions_intensity_gco2_per_kwh": 363.982
}

[rossf7]

I extracted the logic to this function which simplifies the error handling. So we only need a single log.Fatal call.

[rossf7]

This is how we add viper for managing the config by binding it to the cobra CLI flag.

https://github.com/spf13/viper#working-with-flags

[rossf7]

Sorry the diff is a bit hard to follow here. All the logic for getting the country code is moved to the getCountryCode func.

[mrchrisadams]

I'm happy for this to be merged in @rossf7.

There's only one query I have here when we prompt users for a country code.

However, I'm ok with us splitting that out as a separate issue, and for us to it to talk about the first time experience across all the providers we currently use.

[mrchrisadams]

Do you think it's worth making explicit that the country code is being used to make the request/lookup against our set of country / carbon intensity codes?

I know the returned JSON blob mentions that the country and country code, but for the first time, when I looked over it, I felt like having a short one line outlining what was about to happen before showing the returned value would make it easier to understand what was happening.

This probably isn't needed on subsequent uses, but I think it provides a more gentle way into this domain.

[rossf7]

Yes, I agree I think we should explain more what is going on.

I've been thinking we could add an --output flag that defaults to text but also supports JSON.
The text output could walk the user through choosing a provider and region. As well as linking to our developer site for more docs. WDYT?

[mrchrisadams]

yes. would you mind creating an issue for this? I think this would be a good one to include Fershad for this, so he can create some tutorials and add some reference to it in the developers.tgwf site

[rossf7]

@mrchrisadams I created #32 for this. I agree it would be good to work with Fershad on this and to have some tutorials.

[rossf7]

Thanks @mrchrisadams I'm going to merge this. I'll create a new issue for the first time experience.