Default to rollups when --framework is not defined

[endersonmaia]

📚 Context

With the addition of the cartesi rollups <subdommands> command preparing for the support of cartesi coprocessor <subcommands> we should default to the rollups command when rollups or coprocessor are not defined.

✔️ Solution

We should add a --framework CLI argument that will control if rollups or coprocessor will be used.

[tuler]

This can be hard to do and also can be hard for the user to understand.
Consider we add a framework = "rollups" | "coprocessor" to the cartesi.toml configuration, with a default value of "rollups".

Now, what should be printed with the cartesi start --help command?
IMO it should print the help of the cartesi rollups start --help or the help of cartesi coprocessor start --help, dynamically depending of the value of the framework coming from the cartesi.toml.

I don't know if this is easy or possible to do with commander.
And even if it is it might be confusing for the user.

[endersonmaia]

Thinking better about this, maybe we should deprecate the root build command.

As far as I understood, the goal to have a framework= at config.toml was to run cartesi build identify if it was a rollups or a coprocessor.

What if we only support cartesi rollups build or cartesi coprocessor build explicitly ?

This is related to the PR #174 and #175

@tuler let's define a better scope for this, so that the coprocessor integration to the CLI can move forward.

[tuler]

The problem of having a root command is that each subcommand have different options, which are not “transferred” to the root command.

[endersonmaia]

The problem of having a root command is that each subcommand have different options, which are not “transferred” to the root command.

So I'm proposing to not have a build root command.

And other command we see necessary.

For me, we only need root command for

• cartesi doctor
• cartesi clean
• cartesi --version`
• cartesi help

Those depends on .cartesi/ populated from a build but could stay on root

• cartesi hash
• cartesi shell

Everything else, like create, build, start, stop, status would be under rollups or coprocessor.