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

fix[cli]: format long subcommand descriptions #3227

Merged
merged 4 commits into from
Apr 28, 2022

Conversation

KuthumiPepple
Copy link
Contributor

@KuthumiPepple KuthumiPepple commented Apr 21, 2022

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 the cmd.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

fix(cli): format long subcommand descriptions

@squakez
Copy link
Contributor

squakez commented Apr 21, 2022

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 --help to see how it looks like.

@KuthumiPepple KuthumiPepple marked this pull request as ready for review April 22, 2022 00:35
@KuthumiPepple
Copy link
Contributor Author

So I have implemented the fix. What do you think?

make some experiment and post the result of any --help to see how it looks like.

Ok, here is an image of the result of running kamel run --help

Screenshot from 2022-04-22 01-54-24

Copy link
Contributor

@squakez squakez left a 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
Copy link
Contributor

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?

Copy link
Contributor Author

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

@KuthumiPepple
Copy link
Contributor Author

Before this is merged, I'll suggest we move this lengthy description to the more appropriate Long field and use a shorter description (perhaps the first sentence alone) for this Short field.

@squakez
Copy link
Contributor

squakez commented Apr 22, 2022

Before this is merged, I'll suggest we move this lengthy description to the more appropriate Long field and use a shorter description (perhaps the first sentence alone) for this Short field.

Sure, feel free to add a commit to fix it.

@KuthumiPepple
Copy link
Contributor Author

Sure, feel free to add a commit to fix it.

Ok I will

@KuthumiPepple
Copy link
Contributor Author

Sure, feel free to add a commit to fix it.

I've added a commit for this. You can go ahead and merge

@KuthumiPepple
Copy link
Contributor Author

KuthumiPepple commented Apr 26, 2022

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?

@KuthumiPepple
Copy link
Contributor Author

Turns out making further updates isn't a problem. I've implemented the changes I suggested in the previous comment.
Here is an image of the result of running kamel install --help:
Screenshot from 2022-04-26 15-58-21

@KuthumiPepple
Copy link
Contributor Author

KuthumiPepple commented Apr 27, 2022

@oscerd @tadayosi could either of you please review my latest changes. Squakez seems to be busy atm.

@squakez
Copy link
Contributor

squakez commented Apr 27, 2022

@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.

@squakez
Copy link
Contributor

squakez commented Apr 27, 2022

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.

@KuthumiPepple
Copy link
Contributor Author

KuthumiPepple commented Apr 27, 2022

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.

@squakez
Copy link
Contributor

squakez commented Apr 27, 2022

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?

@KuthumiPepple
Copy link
Contributor Author

KuthumiPepple commented Apr 27, 2022

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.

Copy link
Contributor

@squakez squakez left a 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:
Copy link
Contributor

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

Copy link
Contributor Author

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:
Copy link
Contributor

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

Copy link
Contributor Author

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}}
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do

@KuthumiPepple
Copy link
Contributor Author

The suggested change has been implemented.

@squakez squakez merged commit b0e252e into apache:main Apr 28, 2022
@squakez
Copy link
Contributor

squakez commented Apr 28, 2022

Failures unrelated to this change

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

Successfully merging this pull request may close these issues.

[CLI] Format long subcommand descriptions
2 participants