GitLab

It takes some space and it looks like it
applies to the description too.

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

I didn't know there were dragons here.

When casting errors we've gotta be careful. Apparently both values and
pointers satisfy the error interface. Type checking for one doesn't
catch the other.

cc @whyrusleeping @mappum @jbenet

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

feat(commands) add ClientError(msg) helper and use it to return a fancy error to the client in the tour

@jbenet this exists now

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

Also:
- map[cmds.EncodingType]cmds.Marshaller -> MarshalMap

cc @mappum @maybebtc

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

@mappum

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

boilerplate

I know you'll love this one @mappum

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

nil function

cc @jbenet @mappum

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

Attention @maybebtc @mappum

I cleaned up + simplified the main flow. Now, all printing
is contained inside main itself! (:cheer:). I do this with
the help of a cmdInvocation struct that has both
a Parse and Run. The only major clunkiness left is that the
"CallCommand" is still its own function. But *shrug*.

Please test it works as we would expect. i changed much of
the flow, so likely that i missed a complicated edge case.

main roadmap:
- parse the commandline to get a cmdInvocation
- if user requests, help, print it and exit.
- run the command invocation
- output the response
- if anything fails, print error, maybe with help