-
Notifications
You must be signed in to change notification settings - Fork 569
feat: Documentation and plugin system for parsers #4200
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
feat: Documentation and plugin system for parsers #4200
Conversation
3454a25
to
af1e163
Compare
af1e163
to
ead3ea1
Compare
@terriko This is ready for review when you have time. Thank you in advance :) |
Asciinema: https://asciinema.org/a/664036 Signed-off-by: John Andersen <[email protected]>
95b3627
to
526f45f
Compare
Signed-off-by: John Andersen <[email protected]>
de41d84
to
f29b251
Compare
Was there a specific motivation for this? I ask because our current plugin system is the thing blocking us from moving to pyproject.toml from setup.py. And honestly, that's not a thing we need but it would make a bunch of our config go into that file so we don't have to have quite as many separate configs for our linters. So I'd been wondering if we should refactor away from those plugins next time we do a big refactor. Do you know of anyone supporting out of tree stuff that this would affect? I love refactoring the parsers to be more atomic in that they actually know what files they're scanning for, and I love the better documentation. But I"m wondering if we should rethink the plugins now before we add more of them, I guess? |
Adding: Got some more info on the use case from @pdxjohnny and I agree that this is probably the best solution. I'll be back to do a more nitpicky code review later. |
I will start on un-entrypoint-zing in-tree checkers so we can move to |
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.
Okay, there's a lot of todos in here but it doesn't feel like any of them need resolving before we can proceed.
I also feel like "parsers" may be as confusing here as "checkers" is for people with the binary checkers, but I don't have any brilliant ideas that pre-emptively solve the inherent issues of communicating in human language, so I'm going to trust in documentation to explain and we'll see how it goes, I guess?
Thanks again for this! I'm going to go ahead and merge now.
Woohoo thank you!!! |
Parser
s in the same way that checkers have long had. This enables out of tree Parsers for custom CVE finding tooling.