Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion] Improve the existing commands and follow as convention: cmd domain verb #448

Open
cmoulliard opened this issue Nov 14, 2024 · 6 comments
Labels
enhancement New feature or request

Comments

@cmoulliard
Copy link
Contributor

TODO

Improve the existing commands and follow as convention: cmd domain verb which is a
a more user's friendly way to play with commands. See by example tools as: podman, docker, quarkus, etc

Examples

idp = idpbuilder

idp clusters // List the clusters
idp cluster ls // list the clusters
                  create --name // Create a new cluster
                  delete --name // Delete a cluster
idp cluster <name> // Shortcut to get the detail of a cluster => equivalent to idp cluster get <name>

If we adopt this convention, then we could also propose as commands

idp secrets => idp creds // List the packages and their credentials
      cred ls
      cred get <package_name> // List the cred of the package name
      cred update --username --password -p <package>

and for the urls (= ingress resources)

idp urls
      url ls // List the urls of the packages installed and hosted behind ingress
      url get <package_name> // List the cred of the package name

Originally posted by @cmoulliard in #445 (comment)

@cmoulliard cmoulliard changed the title Improve the existing commands and follow as convention: cmd domain verb [Suggestion] Improve the existing commands and follow as convention: cmd domain verb Nov 15, 2024
@cmoulliard cmoulliard added the enhancement New feature or request label Nov 15, 2024
@nabuskey
Copy link
Collaborator

I would rather stick with the kubectl convention. e.g. kubectl get pods kubectl get secrets. Personally, I find that convention easier to read.

@greghaynes
Copy link
Contributor

I honestly don't have a strong opinion on the command structure, I only have a strong opinion that it remain internally consistent.

@blakeromano
Copy link
Contributor

No strong opinion but I agree with consistency. I also think if we are making a breaking change like redoing the CLI commands should be a target for 1.0 release.

@abangser
Copy link

+1 to consistency over which specific structure gets landed on.

It does feel like despite our best efforts to stay unsurprising to users, we already have a clear divide between kubectl (kubectl [command] [TYPE] [NAME] [flags]) vs other proposed examples (which I would translate your proposal to make it comparable as: idp [TYPE] [command]).

One thing to call out is that docker does seem to be in the command then type format given an example of docker create [OPTIONS] IMAGE [COMMAND] [ARG...]. Though I may be reading this differently than you?

Also, while I am not familiar with the codebase for this CLI, but code reuse/testability/structure should be a part of the decision so if someone more familiar can speak to that it may help decide as well.

@cmoulliard
Copy link
Contributor Author

cmoulliard commented Nov 25, 2024

One thing to call out is that docker does seem to be in the command then type format given an example of docker create [OPTIONS] IMAGE [COMMAND] [ARG...]. Though I may be reading this differently than you?

docker like podman (or others) are following also the convention

CLI <DOMAIN | TYPE> <VERB>

docker container create|exec|start|stop|ls|etc
docker image pull|push|tag|save|rm|pruneetc

@nabuskey
Copy link
Collaborator

Changing command structure like this requires we refactor the internal cmd structure, update all documentation, update blog posts, update stacks, etc. Is the effort worth it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants