Tagging some cobra repo examples:
https://github.com/alexellis/arkade/tree/master
https://github.com/rwxrob/lab/tree/b3d097cabbe7225388b1159ce801edc1de7e9912/go/cobra/simple-go
https://github.com/cli/cli/tree/trunk/pkg/cmd
https://www.youtube.com/watch?v=WOLrDPsswLE

Weather uses the vars branch to have persistent storage for API Key, location and region ids. Cobra has no equivalent command package. Will have to either set them as env vars or use persistent flags.

Breakdown of the current command map:

• weather
  • site
    • list
    • find
    • set
    • forecast

I could use Viper to load in a env file from os.UserCacheDir() I can put this stuff in the app package? or make a new package called conf?
https://dev.to/techschoolguru/load-config-from-file-environment-variables-in-golang-with-viper-2j2d

Having mixed thoughts on the project structure. Git hub gh cli groups the cmds by package and each sub command gets its own package. This does mean that you will have multiple create packages in different places for common command names. I did initially think that there would be a conflict but from go pov it would package them together even if the same package names are in different directories during compile. Not entirely sure this is a good approach either.

Option 1:

• cmd/
  • site/
    • list/
    • find/

Option 2:

• cmd/
  • site.go
• site/
• region/

With option 2, the business logic is lifted to a higher level. I also put all site cmds, including its sub commands inside site.go and have the business logic live in site/ and region/.

Whereas with option 1, there is command level isolation. More directory depth.

Reviewing what I have now, lets keep it simple and go for option 2. If it gets too large, then I can look to refactor to option 1.

Or alternatively, I can still put site.go into site/ and rename to cmd.go and export Cmd. So imports to the root cmd will be site.Cmd

Actually, cobra already has a OnInitialize function to load in config file function. This effectively makes the conf package redundant.

Should be added to the root node based.

Actual implementation is still to keep the conf sub command because it's useful to have around as a way to output the conf as a command

Current command tree:

weather conf init
weather conf data

weather site list
weather site set
weather site forecast