proposal: simplify the plugin system about cli HOT 7 OPEN

Additional notes:

• Since the serialization of cobra.Command is not complete, issues like #3350 can raise on a regular basis. With the simplification this is no longer a problem.
• The simplification will break existing plugins. Authors will have to update their plugin code to make it works with the CLI version that has the simplification.

from cli.

I think this could be an interesting topic to discuss on the Community call 👍

from cli.

Not being able to mount commands in places like ignite chain and ignite scaffold means there are limits to how plugins can really "extend" CLI from users' point of view. Each org extending the CLI would have to mount under their own top-level name.

ignite acme scaffold foo instead of ignite scaffold foo.

And it will make it harder for us to extract functionality into independent plugins as well.

from cli.

Is it possible to enforce flags to be submitted after the command?

❌ ignite scaffold --path ./xxx/yyy wasm

✅ ignite scaffold wasm --path ./xxx/yyy

from cli.

Is it possible to enforce flags to be submitted after the command?

❌ ignite scaffold --path ./xxx/yyy wasm

✅ ignite scaffold wasm --path ./xxx/yyy

Yes that's probably doable, and after we can safely truncate. I just wonder if this isn't going to be complicated if the command also has arguments.

That said, the plugin still needs to redefine the path flag internally to be able to read it, whereas this flag is defined in the parent comment scaffold.

from cli.

But arguments will follow the command, right? You can't have ignite scaffold arg1 arg2 foo, it's always ignite scaffold foo arg1 arg2.

from cli.

You're right, maybe it's not that complicated.

from cli.