Move log tokenizer to lib/strvals package
#3446
Conversation
Up until now the tokenizer implementation was only used to parse the log output option configuration. With our current intention of using this format for other options, such as traces output, it becomes evident that this implementation should be moved away from the log package and into a more generic one.
There was a problem hiding this comment.
LGTM!
My only nit is that I kind of don't like parseutils in part due to the utils part.
But tokenizer.Tokenize is no better as well as tokens.Parse or tokens.New
So unless @oleiade comes up wiht something better I guess this is it.
Yep, to be honest I don't quite like it either. I considered |
There was a problem hiding this comment.
I have explored a few options, most of which would turn out to require more effort, and I'd rather unblock you instead 🙇🏻
I would vote for making the name of the package as specific and explicit as possible, rather than broad and generic. Thus, I would suggest something along the lines of lib/logparser, or lib/kvparser package or something along those lines instead.
My reasoning is that the parsing mechanism described in the package is quite specific to the key=value,... format, which is meant to be used in logs, and I don't think that calling parseutils.Tokenize is very clear on what to expect from it: I'm gonna parse something, and tokenize it, but it feels generic when the implementation is actually specific to a given format.
I wouldn't block the PR over this though, and although I would find parseutils subpar, it would be good enough if we can't reach an agreement.
|
The original code was loosely based on what https://pkg.go.dev/k8s.io/helm/pkg/strvals does. So I guess
but I am also okay with I also prefer to not block @ka3de but if we have a clearly better name that we agree on it seems like a good idea to take 5 minutes. And yes |
|
I like |
I guess this depends also on whether this package will hold more parsing implementations in the future. But as of now I agree that the implementation is pretty specific.
My understanding is that the format implemented by Edit: On the |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #3446 +/- ##
==========================================
- Coverage 73.36% 73.33% -0.03%
==========================================
Files 261 261
Lines 19742 19769 +27
==========================================
+ Hits 14483 14498 +15
- Misses 4365 4373 +8
- Partials 894 898 +4
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
ka3de
changed the title
lib/parseutils packagelib/strvals package
|
I have no permission to merge the PR. Could you merge this please? |
What?
Moves the tokenizer implementation, currently only used to parse the log output option configuration, to a more generic package.
Why?
Up until now the tokenizer implementation was only used to parse the log output option configuration. With our current intention of using this format for other options, such as traces output, it becomes evident that this implementation should be moved away from the log package and into a more generic one.
Checklist
make lint) and all checks pass.make tests) and all tests pass.Related PR(s)/Issue(s)
Related #3445