okteto up vs okteto dev up as the main command to use your remote dev env

[rberrelleza]

#2502 is proposing to merge all the 'development' commands into a single dev subcommand. The benefits of this proposal are:

1. make the commands consistent with the okteto command action form
2. have them all organized under a single command.

The cons are:

1. We have to type more to execute the command
2. If we want to maintain compatibility, we need to maintain aliases for all commands, resulting in duplicated commands and docs (and potentially, user confusion)

A separate proposal is to leave okteto up, okteto down, okteto exec as they are today. The benefits of this proposal are:

1. The command that people use the most (okteto up) is short
2. Our users are already used to this command, so there's no need to learn something new
3. We don't have to maintain new aliases.

The main downside of this proposal is that these commands will not follow the okteto command action form, making the commands less uniform, and potentially, less intuitive.

We need your help

We are looking for feedback from the broader Okteto community on this topic. What do you think? Do you have a preference? Should we support both?

[RinkiyaKeDad]

We have to type more to execute the command

Our users are already used to this command, so there's no need to learn something new

Since okteto up will continue being an alias for okteto dev up, I don't think these should be that problematic. But I do agree with your concern about duplicated commands, and that how we document and present this information could cause confusion for users.

IMO if we think of Okteto CLI as primarily a tool for creating development environments (and not deployment-related tasks), then it is okay for us to not follow the okteto command action form for the "core" set of commands (up, down, etc) which provide the main functionality.

Because if we do that, then in essence, we're down to just 2-3 commands, and everything else just becomes an action. We can stick with the okteto command action form for commands which compliment dev environments like deploy and destroy. This way, we'd have a good structure of a core set of commands that provide the functionality of launching and destroying dev envs, and anything else that supplements this follows the command/action approach.

[pchico83]

I would duplicate:

• okteto up and okteto dev up
• okteto down and okteto dev down
• okteto exec and okteto dev exec
  It's a small overhead on the number of commands, and the okteto dev xxx structure maps the manifest structure and might help to discover available commands.
  @rlamana WDYT?

[rlamana]

+1

I thought that was always the idea, to do both:

1. Group commands based on the NOUN VERB pattern and match the okteto manifest structure. So these actions would be under DEV.
2. Keep most commonly used commands as aliases at the first level, including UP, DOWN, and EXEC.

[rberrelleza]

might help to discover available commands.

Do you have any suggestions on how can we validate that assumption before doing the work?

[rlamana]

I've been giving this a lot of thought and I still have mixed feelings, but honestly, I now lean more towards keeping it as it is now.

The core of our product revolves around the concept of dev environments. We conceived the CLI 2.0 around this concept, and our main command up is now capable of getting everything ready and launching the entire dev environment by automatically executing also the build and deploy commands.

If we add the dev subcommand, it makes sense that it contains all of the dev environment related commands, not only up, down, and exec. This means also adding the current build, deploy, and destroy which are part of the dev environments life cycle.

I guess our main problem is to think that since we have subcommands (a good practice to tackle our CLI growing complexity), everything should be grouped that way to be coherent, but that isn't necessarily true. If our product's core is dev environments, why shouldn't the CLI 1st level command be those related to them? Doing some research shows that many CLI tools use this pattern with commands and subcommands, for example, the docker CLI tool.

I vote to keep them as they are for now.

[rlamana]

I like to think of all this related to this other issue: #2536

With this approach we can created the following:

1. okteto ls to list all dev environments in current context
2. okteto service ls to list all services in the current context (we will have to add the service subcommand).

[RinkiyaKeDad]

+1 for the organized structure, it really improves the UX a lot!

[pchico83]

+1 for the organized structure and keeping commands/subcommands as they are today

[jLopezbarb]

+1 for the organised structure. This looks amazing!!

[AgustinRamiroDiaz]

Great idea about organizing the commands! I'll still need to think a bit more about the listing syntax