-
Notifications
You must be signed in to change notification settings - Fork 124
Migrate to github.com/olekukonko/tablewriter 1.0 #2590
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
Conversation
Tablewriter introduced several breaking changes in its 1.0 version, both in its APIs and in its behaviour. Adapt the code to the new major.
+-------------+----------------------------+-------------------+-------+-----------------+ | ||
| Production | 1.1.0-beta1 (1.0.0, 1.0.1, | Beta | Foo | Foo integration | | ||
| | 1.0.2) | | | | | ||
+-------------+----------------------------+-------------------+-------+-----------------+ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrapping seems to change in 1.0, I haven't managed to mimic old behavior, but the new looks better.
cmd/status.go
Outdated
table.SetRowLine(true) | ||
table.AppendBulk(environmentTable) | ||
table.Render() | ||
func formatHeaders(headers []string) []string { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was done automatically in v0, I haven't found how to do this in v1.
cmd/tables.go
Outdated
}, | ||
}, | ||
Settings: defaultTableRendererSettings, | ||
Symbols: tw.NewSymbols(tw.StyleASCII), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could remove this line to change to the default style in v1, that would render tables like this (in my shell all lines are continuous):
$ elastic-package status -C ./packages/apache --info kibana.version
Package: apache
Owner: elastic/obs-infraobs-integrations
Package Versions:
┌─────────────┬─────────┬─────────┬────────────────────┬───────────────────────────────┬───────────────────┐
│ ENVIRONMENT │ VERSION │ RELEASE │ TITLE │ DESCRIPTION │ KIBANA VERSION │
├─────────────┼─────────┼─────────┼────────────────────┼───────────────────────────────┼───────────────────┤
│ Local │ 2.0.0 │ GA │ Apache HTTP Server │ Collect logs and metrics from │ ^8.13.0 || ^9.0.0 │
│ │ │ │ │ Apache servers with Elastic │ │
│ │ │ │ │ Agent. │ │
├─────────────┼─────────┼─────────┼────────────────────┼───────────────────────────────┼───────────────────┤
│ Production │ 2.0.0 │ GA │ Apache HTTP Server │ Collect logs and metrics from │ ^8.13.0 || ^9.0.0 │
│ │ │ │ │ Apache servers with Elastic │ │
│ │ │ │ │ Agent. │ │
└─────────────┴─────────┴─────────┴────────────────────┴───────────────────────────────┴───────────────────┘
FTR, this is the output with ASCII style:
$ go run github.com/elastic/elastic-package status -C ./packages/apache --info kibana.version
Package: apache
Owner: elastic/obs-infraobs-integrations
Package Versions:
+-------------+---------+---------+--------------------+--------------------------------+-------------------+
| ENVIRONMENT | VERSION | RELEASE | TITLE | DESCRIPTION | KIBANA VERSION |
+-------------+---------+---------+--------------------+--------------------------------+-------------------+
| Local | 2.0.0 | GA | Apache HTTP Server | Collect logs and metrics from | ^8.13.0 || ^9.0.0 |
| | | | | Apache servers with Elastic | |
| | | | | Agent. | |
+-------------+---------+---------+--------------------+--------------------------------+-------------------+
| Production | 2.0.0 | GA | Apache HTTP Server | Collect logs and metrics from | ^8.13.0 || ^9.0.0 |
| | | | | Apache servers with Elastic | |
| | | | | Agent. | |
+-------------+---------+---------+--------------------+--------------------------------+-------------------+
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just take a look locally to the new default style in V1, and it looks better.
I guess that change would break the tests in CI, have you tested that? I hope it should be easy to update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is easy to change 🙂 We have a -generate
flag. Changed and tests updated.
cmd/tables.go
Outdated
}, | ||
}, | ||
Settings: defaultTableRendererSettings, | ||
Symbols: tw.NewSymbols(tw.StyleASCII), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just take a look locally to the new default style in V1, and it looks better.
I guess that change would break the tests in CI, have you tested that? I hope it should be easy to update.
// headerCellFilter mimics behaviour of tablewriter v0, where some symbols where replaced | ||
// with spaces. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
colorCfg := defaultColorizedConfig() | ||
table := tablewriter.NewTable(w, | ||
tablewriter.WithRenderer(renderer.NewColorized(colorCfg)), | ||
tablewriter.WithConfig(defaultTableConfig), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just found that elastic-package stack status
and other commands use another dependency to render data into tables: "github.com/jedib0t/go-pretty/table"
cmd/stack.go: "github.com/jedib0t/go-pretty/table"
internal/benchrunner/runners/pipeline/format.go: "github.com/jedib0t/go-pretty/table"
internal/benchrunner/runners/pipeline/format.go: "github.com/jedib0t/go-pretty/text"
internal/benchrunner/runners/rally/report.go: "github.com/jedib0t/go-pretty/table"
internal/benchrunner/runners/rally/report.go: "github.com/jedib0t/go-pretty/text"
internal/benchrunner/runners/system/report.go: "github.com/jedib0t/go-pretty/table"
internal/benchrunner/runners/system/report.go: "github.com/jedib0t/go-pretty/text"
internal/testrunner/reporters/formats/human.go: "github.com/jedib0t/go-pretty/table"
Probably, it could be used eventually the same dependency everywhere (in follow-ups), WDYT ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good one, not sure which one is better.
By now I have done some changes for consistency in 80f5579:
stack status
uses tablewriter now, so at least everything undercmd
has consistent tables. This changesstack status
to show colors, bold headers and lines between rows:
- Default style modified to "Rounded", it looks nicer, and will be consistent with the other tables.
From this point, not sure what to do, do you have an opinion? go-pretty
looks simpler, but also we are not using many formatting options, so at the end it may be similar in complexity.
Basically we have three options:
- Migrate everything to go-pretty.
- Migrate everything to tablewriter.
- Leave things as they are now, using tablewriter for commands, and go-pretty for test reports.
If we go for using the same library, I can create an issue to delay the decision (maybe forever? 😅)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From this point, not sure what to do, do you have an opinion?
go-pretty
looks simpler, but also we are not using many formatting options, so at the end it may be similar in complexity.Basically we have three options:
- Migrate everything to go-pretty.
- Migrate everything to tablewriter.
- Leave things as they are now, using tablewriter for commands, and go-pretty for test reports.
I guess, it would be good to just use one dependency for rendering tables. But I don't have an strong opinion in which one to choose.
For me, it could be kept as it is now in this PR. Trying to keep the usage of tablewriter
in cmd
and go-pretty
for other usages.
If we go for using the same library, I can create an issue to delay the decision (maybe forever? 😅)
We could create an issue as a change that would be nice to have (using just one library).
I think I prefer the previous, more compact format for
stack status
, I have modified it to:
Comparing both versions, I also prefer the previous one. The one shown in the screenshot here: #2590 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Follow up issue created #2604.
|
||
config := defaultColorizedConfig() | ||
config.Settings.Separators.BetweenRows = tw.Off | ||
table := tablewriter.NewTable(cmd.OutOrStderr(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am using cmd.OutOrStderr()
here because it is what cmd.Println
does. I found out by seeing that scripts/test-stack-command.sh
uses 2>
to redirect its output for comparison.
We should also work on consistency of outputs, I would say that all these tables should go to stdout.
Not to change in this PR in any case.
💛 Build succeeded, but was flaky
Failed CI StepsHistory
cc @jsoriano |
Tablewriter introduced several breaking changes in its 1.0 version, both in its APIs and in its behaviour.
Adapt the code to the new major, configuring renderer to behave as similar as possible as in v0.
Take the opportunity to refactor the related code to reuse table settings where possible.
Supersedes #2591, #2597, #2600.