-
Notifications
You must be signed in to change notification settings - Fork 350
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
fix[cli]: format long subcommand descriptions #3227
Conversation
Thanks for the work. I think it could be a way to fix it. You can proceed, make some experiment and post the result of any |
47c34c7
to
36054f0
Compare
36054f0
to
8594cfc
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.
Looks preetty!
Let's remove the generated.deepcopy files before merging, though.
go.mod
Outdated
@@ -19,6 +19,7 @@ require ( | |||
github.com/magiconair/properties v1.8.6 | |||
github.com/mitchellh/go-homedir v1.1.0 | |||
github.com/mitchellh/mapstructure v1.4.3 | |||
github.com/moby/term v0.0.0-20210619224110-3f7ff695adc6 |
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.
Any reason why not to use golang.org/x/term
instead?
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.
No good reason. It was just the first package I saw while searching for a way to get the terminal size. I'll change it to golang.org/x/term
Looks preetty!
It sure does
Let's remove the generated.deepcopy files before merging, though.
Ok
8594cfc
to
cfeaae6
Compare
Before this is merged, I'll suggest we move this lengthy description to the more appropriate |
Sure, feel free to add a commit to fix it. |
Ok I will |
cfeaae6
to
ee15d95
Compare
I've added a commit for this. You can go ahead and merge |
Hi, it's been 4 days since this contribution was approved, is there a reason why it hasn't been merged yet? I also noticed that nothing has been merged recently. OK, this is a small wall of text. I have been thinking about the current solution and I do have a suggestion for an improvement but I don't know if making any further changes would disqualify this contribution from been considered / evaluated by the mentors (I am an applicant for the Outreachy internship and have already submitted this fix as one of my contributions). Now, as to my suggestion, although the current solution works for us, I think it affects program readability (especially the replacement I did on the template string). Without adding some comments, a programmer viewing the code may find it a bit difficult to understand why I replaced that part of the string. Another problem is that future modifications/customization to the template string will not be straightforward. To eradicate these two issues, I'd suggest that in our project code, I define the usage template string customized with the desired changes by default, so we can all see the template and easily modify it in the future when needed. What do you think? |
c0eba3e
to
b573c5b
Compare
@KuthumiPepple we may have several things on going, so please, wait for some time before pushing for an answer. I will have a look as soon as possible. In the while, please, have a look at the checks failure to understand if they are related to your changes. |
I had approved already, but I had a look at this last commit b573c5b after the approval and I am not sure why we want to expose the whole template. Can you please clarify the goal behind this last change? Thanks. |
The goal is to make modifications (both replacements and additions) to the template easier. Like in this case I no longer have to retrieve, replace and reset the template string just to make a modification. All I had to do was modify the needed area in the template. Without exposing the template, future alterations (especially additions) to it would be cumbersome. I also couldn't think of any security concerns not to do so but I may be wrong. |
Thanks @KuthumiPepple. What I am concerned about is the presence of sections we are not using. Could we maybe have it a shorter template version to only consider usage, flags, global flags instead? |
I'm not sure I fully understand what you mean. Are you talking about having a shorter usage template for all the commands or for this specific issue? This most recent change sets the usage template for kamel and its sub-commands. We are no longer using the default. We are defining ours, hence the reason for the other sections like "Aliases" and "Available commands". Edit: If you are talking about all the commands then sure we can cut some out but I'd have to look through each command and ensure that the associated fields are not set. |
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's my point. As we are defining a template, I suggest we only cover what we need. We may introduce (and maintain) any further section when we eventually need it.
pkg/cmd/root.go
Outdated
{{.UseLine}}{{end}}{{if .HasAvailableSubCommands}} | ||
{{.CommandPath}} [command]{{end}}{{if gt (len .Aliases) 0}} | ||
|
||
Aliases: |
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 don't use aliases, I'd remove this section
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.
Will do
pkg/cmd/root.go
Outdated
Aliases: | ||
{{.NameAndAliases}}{{end}}{{if .HasExample}} | ||
|
||
Examples: |
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 don't use examples, I'd remove this section
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.
Will do
pkg/cmd/root.go
Outdated
Global Flags: | ||
{{.InheritedFlags.FlagUsages | trimTrailingWhitespaces}}{{end}}{{if .HasHelpSubCommands}} | ||
|
||
Additional help topics:{{range .Commands}}{{if .IsAdditionalHelpTopicCommand}} |
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'd remove this section as well
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.
Will do
The suggested change has been implemented. |
62dd3bb
to
256be07
Compare
Failures unrelated to this change |
Closes #2318
@squakez This is a draft PR for now. I would like to hear your thoughts on my plan to tackle this issue, to know if I'm on the right track. So I think the problem comes from the usage template string defined in the cobra package. Specifically this:
{{.LocalFlags.FlagUsages}}
. The returned string is not wrapped and so when a line break occurs, the output written to the terminal is not in order. My plan is to replace the.LocalFlags.FlagUsages
with a template function that calls thecmd.Flags().FlagUsagesWrapped
function. As you suggested previously, I'd need to get the terminal size. I will probably use the size to set the flag description length. What do you think am I on the right track? If not what suggestions could you give me?Release Note