-
Notifications
You must be signed in to change notification settings - Fork 485
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
ls: format opt #1787
ls: format opt #1787
Conversation
I was wondering if formatting should be moved to a |
I know there's been some shuffling around in the past between "a single formatter package, containing formatting for all (sub) commands / object-types", and "per-object-type formatters" We need to have a look what works best; the "problem" I can see with putting all formatting in a single package, is that that package would now have to depend on all object-types (packages), whereas keeping it "per-object" could (potentially) allow for more granular imports (e.g. "I only need formatting for Of course, "common" / "generic" code should be put in a place that we can share. |
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.
Also quick check (ISTR we have some commands that do "one" and some that do "the other); for the JSON output, do we want to use "jsonlines" (https://jsonlines.org), or an array?
- I know
jq
is perfectly able to handle either - Other tools may have more difficulty with line-delimited
- For some commands we used line-delimited, because we had to handle "streaming" responses (and didn't want to load everything into memory before being able to display (👈 but this probably doesn't apply to this command (I think we would have it all in memory, nothing streaming, right?)
commands/ls_print.go
Outdated
case formatter.TableFormatKey: | ||
format = lsDefaultTableFormat |
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 may have been inconsistent with this; slightly wondering if we should consider the default to be a table
or not. (because of the nested presentation). We probably called it "table" for docker service ps
(or which one was it?)
The default presentation COULD be considered more of a tree
format (moby/moby#44582 (comment)), which could keep the road open to implement a "flat" table presentation.
(I haven't fully thought this through though!) /cc @jalonsogo
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.
That sounds like major change that should be first done upstream and then tackled in cli plugins no?
docs/reference/buildx_ls.md
Outdated
| `.IsNode` | `true` if entry is a node | | ||
| `.IsCurrent` | `true` if entry is the active builder | |
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.
Hm. I'm not sure I'm a fan of this approach for writing templates, I think we lose something from the structured data.
I think I'd rather have .
be the builder, and have a .Nodes
property contain a list of nodes that can be range
d or index
d to get the node details out.
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.
Yeah me too but that's how the cli api does it today using the formatter context. I don't think there is something else than json-lines in the cli atm (cc @thaJeztah)
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.
Ah I see @thaJeztah commented on this #1787 (review). I would also prefer json array tbh.
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.
@jedevc was that specific about the .IsCurrent()
? I know we added that because in the past we had *
as part of the name, which was not ideal, and having a separate .IsCurrent()
allow it to be "formatted how you'd like", but still keeping the raw name available to be used.
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.
Ah sorry my bad, comment on the wrong line 😢 I meant to comment on IsNode
.
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 was looking at https://docs.docker.com/engine/reference/commandline/service_ps/ which has services and tasks (similar to us with builders and nodes) and it seems format only handles tasks and not services: https://docs.docker.com/engine/reference/commandline/service_ps/#format
IMO, we can keep it more specific for this PR, and as we grow the functionality we can pick the one that's most natural? I don't expect anyone outside of buildx to use that API (:pray: hopefully :pray:), so we should be fine to change it. It also feels like we might want |
go.mod
Outdated
@@ -120,6 +120,7 @@ require ( | |||
github.com/kardianos/osext v0.0.0-20190222173326-2bc1f35cddc0 // indirect | |||
github.com/klauspost/compress v1.16.0 // indirect | |||
github.com/mailru/easyjson v0.7.6 // indirect | |||
github.com/mattn/go-runewidth v0.0.13 // indirect |
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.
You could decide to bump this to v0.0.14 already; see docker/cli#4251 (v0.0.14 looks to have various performance improvements)
Yes this is the idea: #830 (comment) |
a18a197
to
81c9973
Compare
223fdf2
to
af757c8
Compare
Added
|
33d7426
to
a363846
Compare
d8bb251
to
8cde7d1
Compare
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 seems to make sense to me, but I don't know if there might be compatibility issues with any other CLI commands.
berr = strings.TrimSpace(b.err.Error()) | ||
} | ||
return json.Marshal(struct { | ||
Name 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.
Just confirming, these should not be lowercase?
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.
Yes I don't think we should so we are aligned with the placeholders https://github.com/docker/buildx/pull/1787/files#diff-3d2c8ae27c3eb567b2564a6d5b460040e281261aa98ad464b86fc6a047892dcbR46
Signed-off-by: CrazyMax <[email protected]>
fixes #325
follow-up #830 with just the
format
opt.