Migrate to cobra CLI system

[mappum]

Refactored the CLI commands to use cobra. Nothing outside of the main package (the CLI entry point/commands) is changed by this PR.

Addresses #111

• Now subcommands automatically get a nice help command when running ipfs help <cmd>
• Both long and short flags can be used, e.g. ipfs add -r or ipfs add --recursive
• Flags can now be defined as either persistent or local. For example the --config flag is persistent and can be accessed by any subcommand

[btc]

for readability, may want to perform registration in a single spot. easier to see everything that's registered.

[btc]

centralization also provides ability to choose which commands to include, exclude

[jbenet]

commands should hold their children, as before. sometimes one command may be pointed at by multiple parents. and this should be fine.

[jbenet]

(also makes it really easy to break out subcommands into independent packages that can then be used by other tools (say ipfs name and ipns are the same cmd)

[jbenet]

silly vendoring complicating CR:

[jbenet]

how does cobra return errors? it just prints them out itself??? (arghhh).

[whyrusleeping]

this bothers me.... fork?fork?fork?

[jbenet]

thanks @mappum! made comments up there. i think a lot of these changes are bad for how I want to structure the composability of code. particularly:

• really nice and cleanly separated subcommands
• full control over how command text displays (i.e. override the default auto-generated stuff)
• actually returning errors!!
• auto-generated command listings from help. (try running ipfs commands and ipfs commands help -- which we can later upgraded to generate man pages)

lesser (annoying but whatever) issues:

• static flags

if cobra doesn't allow us to do this, then the global flags thing is really not worth it. one of the reasons i chose & forked commander was to precisely allow this sort of stuff. I think either:

1. we patch the functionality we want (mainly persistent flags?) into our own commander package.
2. fork cobra to make it do what we want it to.

let's wait for thoughts from others, and then either

[mappum]

• The subcommand system still works the same, but with a different API (you can do cmd.AddCommand(subCmd))
• We can override any of the help/usage texts, either with a whole new function, or a new template
• Yeah, unfortunately the error handling (or absence of) isn't too great

A better solution might be to work on a command system that supports commands through multiple transports (CLI, HTTP RPC, raw TCP RPC), and multiple encodings, then just build a CLI system that adheres to that Transport interface. That makes a lot of sense, since most of the commands are only boilerplate for making RPC calls.

That would make adding new commands extremely easy since you can just implement it in one place, and not have to make wrapper CLI/HTTP/etc handlers just to call each command.

[jbenet]

A better solution might be to work on a command system that supports commands through multiple transports (CLI, HTTP RPC, raw TCP RPC), and multiple encodings, then just build a CLI system that adheres to that Transport interface. That makes a lot of sense, since most of the commands are only boilerplate for making RPC calls.

Yeah, I like the sound of this. Can you sketch out what the interfaces would look like?

That would make adding new commands extremely easy since you can just implement it in one place, and not have to make wrapper CLI/HTTP/etc handlers just to call each command.

Yep. Though the devil's in the details (i.e. CLI cmds will still need independent handlers to ensure that the command makes sense to type as a human, and HTTP handlers may still be needed to ensure things still make sense to curl manually, etc etc. I.e. these abstractions are in general really good, and of course it is critical to put in place a common interface they all use (to ensure no logic gets duplicated), but often the automatic, abstract thing is too general to make sense for the UX. So a custom wrapper handler will most likely still be needed to make things nice and usable by humans)

[jbenet]

@mappum @whyrusleeping so what do we do here-- hack our own package to do this? fork cobra to do what we want?

[whyrusleeping]

I think we can fork it. The changes that need to be made arent huge, and we could even name it something like "Taipan: more dangerous than cobra", or alternatively, since we would be fixing error handling "Anaconda: Probably less dangerous than cobra"

[jbenet]

@whyrusleeping haha yes. +9001 to either of those names.