go-arg
go-arg copied to clipboard
Make usage and help output configurable
This is a first pass looking to gather feedback on solving #193, #163, #146 and hopefully also #139.
Essentially, this makes use of text/template to specify the output format. It introduces a buildUsageForSubcommand which uses a string builder to build up the usage string that's then interpolated into the Go template.
I haven't modified any of the tests and they still all pass, which at the very least suggest the behaviour is the same.
The idea is to then make the template settable through arg, like func (arg) UsageTemplate() *template.Template {}, and if no such template is provided then p.usageTemplate would use the const usageTemplate.
The code is a little rough right now, but it's the general direction I'm thinking of. Does this align with what you had in mind?
Codecov Report
Base: 100.00% // Head: 99.71% // Decreases project coverage by -0.28% :warning:
Coverage data is based on head (
f55738a) compared to base (11f9b62). Patch coverage: 95.23% of modified lines in pull request are covered.
Additional details and impacted files
@@ Coverage Diff @@
## master #201 +/- ##
===========================================
- Coverage 100.00% 99.71% -0.29%
===========================================
Files 5 5
Lines 688 699 +11
===========================================
+ Hits 688 697 +9
- Misses 0 1 +1
- Partials 0 1 +1
| Impacted Files | Coverage Δ | |
|---|---|---|
| usage.go | 98.91% <93.33%> (-1.09%) |
:arrow_down: |
| parse.go | 100.00% <100.00%> (ø) |
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
In case for anyone looking along, right now the proposed code only changes the usage generation. But if this is something @alexflint is comfortable with I'll rework it and add the code to customise the help output too.
Thanks for putting this together @daenney. I'd like to do support this feature but I'd like to do it in a way where you can configure the organization of all the individual options and positional arguments, control how the long names, short names, descriptions, and default values are laid out, and so on. In order to do that we will need to finalize the layout of the struct that gets passed in to the template, and at that point it will be difficult to change because doing so will break backwards compatibility. Therefore I'd like to add this as a v2 feature, with a re-worked Command struct that is accessible to users of the library.