Command language consistency?

[metacosm]

Right now, component actions are triggered directly (odo create, odo watch) and there is some value to this model as components could be considered the core entity that odo deals with. However, since other commands follow the odo <entity> <action> <options> language, this makes for an inconsistent UI and reduces learnability/discoverability when compared to a UI where components actions would also follow the odo component create grammar. Wouldn't it make sense to unify the grammar for all commands?

[jorgemoralespou]

Makes sense to have both options, as people would most likely otherwise be confused and type odo component <action> ...

Since in the tool, we're looking for simplicity, and we think that everything a user would alias come by default, we should keep both options. Potentially, giving a hint of the shortest notation on the long notation (configurable as an option), so we educate users at the time we prevent them from getting mad for this intentional lack of consistency.

[kadel]

I would prefer to do either one or the other. Doing both just adds confusion :-|

In the original design, the odo component <name> was meant to be used for switching current components. Then we wanted to add aliases for component commands under odo component. That caused problems as odo component <name> couldn't work anymore (component name conflicting with component commands).

I think that having clear consistent structure for every command like odo <entity> <action> <options> without any exceptions will benefit UX more than short commands.

[marekjelen]

I would like us to have both - the full consistent and stable approach, plus shortcuts.

Whenever shortcut is used odo would print an info message that the user used a shortcut to and that it may change in the future as it’s kind of a convenience way of doing stuff today, but that we will be evaluating the shortcuts and that they may change as the tool is going to evolve.

That would imho strike some kind of compromise to provide both ease of use and consistency. odo would be educating people that shortcuts may disappear when use-cases show that the shortcut should be used for something more important.

odo could also consider "short forms" of the subjects, e.g. odo component might be as well accessible through odo c - similar to what oc and kubectl tools do.

[cdrage]

@kadel

Should we go ahead with this implementation?

I see that we've opened up https://github.com/redhat-developer/odo/issues/998 which is another issue related to these semantics.

[kadel]

Should we go ahead with this implementation?

with what? @cdrage can you please write a summary of what you propose?

[cdrage]

With the above comments, I'd like to implement this via this approach:

• Move odo create commands to odo component create as well as other commands (odo list) in order to have it consistent with other commands for odo.
• Add aliases for the current commands, for example, odo create will link to odo component create
• Change documentation to reflect that we prefer odo component create rather than odo create, but the option for aliasing is there.

[kadel]

@jorgemoralespou what do you think? Does it make sense to have short aliases but refer to full command everywhere in our documentation?

[jorgemoralespou]

Yes, I think I commented that I agree somewhere else. https://github.com/redhat-developer/odo/issues/953#issuecomment-437037247

[kadel]

Yes, I think I commented that I agree somewhere else. #953 (comment)

ah, yes. Sorry, I forgot about that one :-(