UX improvements

[walkowif]

Closes #5.

[github-actions]

Unit Tests Summary

8 tests   8 ✔️  0s ⏱️
2 suites  0 💤
1 files    0 ❌

Results for commit 166cc98.

♻️ This comment has been updated with latest results.

[github-actions]

🧪 Test coverage: 65.38%

Code Coverage Summary

Filename            Stmts    Miss  Cover    Missing
----------------  -------  ------  -------  ------------------------------------------------------------------
cmd/construct.go      161      14  91.30%   53-55, 116-120, 152-154, 238-240
cmd/download.go       164      46  71.95%   49-69, 88-90, 107-109, 136-138, 154-156, 176-178, 219-227, 242-244
cmd/parse.go          102      11  89.22%   35-40, 48-49, 57-59
cmd/renv.go            26       0  100.00%
cmd/root.go           126     123  2.38%    46-127, 134-187
cmd/utils.go           71      31  56.34%   26-28, 50-61, 69-71, 79-81, 86-88, 109-115
TOTAL                 650     225  65.38%

Diff against main

Filename        Stmts    Miss  Cover
------------  -------  ------  -------
cmd/root.go        +4      +4  -0.08%
cmd/utils.go      +24     +12  -3.24%
TOTAL             +28     +16  -1.01%

Results for commit: 166cc98

Minimum allowed coverage is 80%

♻️ This comment has been updated with latest results

[cicdguy]

LGTM. viper does not give you the option for CLI tags precedence over config file inputs out-of-the-box?

[walkowif]

It does, and user can still specify these values in config file as string.
The problem comes from the type difference: cobra flags inputPackageList and inputRepositoryList are bound to string variables, but when we're processing the YAML array with package or repository list, it's easiest to save it to []string by using viper.GetStringSlice(), as opposed to viper.Get().
That's why ParseInput still has to check both the inputPackageList/inputRepositoryFlag (string) and inputPackages/inputRepositories ([]string).

[walkowif]

I also think this kind of implementation (where we use different flag/key names depending on whether the argument is a string or a list of strings), is cleaner and more readable as compared to using the same argument name but storing string or list of strings, depending on whether it comes from a CLI flag, or the config file.

[cicdguy]

Got it, and agreed. It is much cleaner this way. Thanks for the detailed explanation. Good to go!