Comments on remote configuration

[hadjian]

@alexbrdn Testing the remote handling in the CLI:

1. Why use a panic, when the configuration cannot be read? A CLI can exit and a server can refuse to start. An unreadable config is an external error, which doesn't seem to warrant a panic, no? It just dumps a stack trace on the terminal, which could be a nice error message.
   https://github.com/web-of-things-open-source/tm-catalog-cli/blob/71ec3a6ecced7e205172b704c20bfaedcd49ff4f/main.go#L44

2. If you agree, I'd like to improve the error message for the case of multiple remotes with no default. I suggest:
   "push failed: multiple remotes configured, but remote target not specified and no default remote set."

Otherwise it looks quite good already.

[hadjian]

3. What if a fs remote was moved or deleted? Shall we improve the error message for that case?

[alexbrdn]

how do you tell if a remote was moved or the config is wrong?

[alexbrdn]

RE 1: config is read in a package init() function. That is, before the app code has even started. There's no way to let this error float up the stack and be logged nicely, except if we're willing to delay the viper initialization. Which I don't particularly like.

[alexbrdn]

RE 2: in light of the #28, I have removed the concept of default remote altogether. The only command that needs it is the push and it makes more sense to make the default flag mandatory for push, unless there's only one remote configured.

[alexbrdn]

RE 3: I have added a check in FileRemote, which validates before list, versions, and fetch, that the configured root exists and is a directory. I don't know if there's a better way to deal with a moved/deleted directory.