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

Output tables for commands should be the same as kubectl tables #5493

Closed
woodcockjosh opened this issue Sep 29, 2019 · 5 comments · Fixed by #5554
Closed

Output tables for commands should be the same as kubectl tables #5493

woodcockjosh opened this issue Sep 29, 2019 · 5 comments · Fixed by #5554
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/backlog Higher priority than priority/awaiting-more-evidence.

Comments

@woodcockjosh
Copy link
Contributor

woodcockjosh commented Sep 29, 2019

The exact command to reproduce the issue:
minikube profile list

The full output of the command that failed:

|----------|------------|----------------|-----------|--------------------|
| Profile  | VM Driver  |     NodeIP     | Node Port | Kubernetes Version |
|----------|------------|----------------|-----------|--------------------|
| minikube | virtualbox | 192.168.99.169 |      8443 | v1.16.0            |
|----------|------------|----------------|-----------|--------------------|

The operating system version:

minikube version
minikube version: v1.4.0
commit: 90bf0f8ec57f051ac014d3b0db6d9051475874d6

Why don't we use a regular table like kubectl uses without pipe separators? It makes it harder to wrap scripts around minikube when we are doing this. I would expect something like this instead:

PROFILE   VM DRIVER   NODEIP          NODE PORT  KUBERNETES VERSION       
minikube  virtualbox  192.168.99.169  8443       v1.16.0
@woodcockjosh woodcockjosh changed the title Shouldn't use olekukonko/tablewriter Output tables for commands should be the same as kubectl tables Sep 29, 2019
@woodcockjosh
Copy link
Contributor Author

woodcockjosh commented Sep 29, 2019

This issue needs to be resolved before I can open a PR olekukonko/tablewriter#129
olekukonko/tablewriter#130

@medyagh
Copy link
Member

medyagh commented Oct 2, 2019

while I agree to match kubernetes style as much possible, changing this would be a breaking change,

but I purpose ! having the option for the users to have the output in different ways

  • json (this is actually important for people who build tools on top of minikube)
  • no table
  • table
  • custom format, we already support this but needs more documentation and examples and maybe unify it across all commands.

@woodcockjosh
Copy link
Contributor Author

woodcockjosh commented Oct 2, 2019

Yea, I wanted to build something on top of minikube and I saw this really crazy table output and thought. Why don't I just help them become normal :-D. Anyway. The breaking change part I'm not really following. You mean if people built a tool that wraps the shell command? Ok fine you're right but we have to live with that table format forever? It's really hard to awk with a bash script. gah. I personally would be fine if you just had a json format for now as it would solve my use case.

@tstromberg
Copy link
Contributor

tstromberg commented Oct 2, 2019

I personally am OK with breaking users who parse stdout of commands unless they have defined a --format parameter. They are by design an unstable interface otherwise.

Related: #5080 - it sounds like we should have an analogous issue for profile.

@tstromberg tstromberg added kind/feature Categorizes issue or PR as related to a new feature. priority/backlog Higher priority than priority/awaiting-more-evidence. labels Oct 2, 2019
@medyagh
Copy link
Member

medyagh commented Oct 2, 2019

I would happily review a PR that addresses this issue, having json output would make a lot of people happy !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/backlog Higher priority than priority/awaiting-more-evidence.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants