-
Notifications
You must be signed in to change notification settings - Fork 18
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
Toml parser #88
Toml parser #88
Conversation
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.
Thank you for the PR!
There are a handful of hlint suggestions detected in CI: https://github.com/haskell/security-advisories/actions/runs/5537522443/jobs/10106419242?pr=88
In general I'm OK with the change. I'm not a fan of the string-only error values in toml-parser, but we get some benefits with the change (such as printing the TOML, which will be handy if we need to do a bulk schema change).
BEFORE we merge this, I'd like to add parsing tests, including for a whole bunch of failure scenarios (unrecognised keys, invalid values, missing fields, etc). That will give me more confidence in this change. And we should have some tests anyway.
toml-parser has a complete test suite included that has code coverage for all the parsing and decoding logic (checked via hpc) and passes all of the defacto-standard burnt-sushi toml-tests (which is a minor improvement over the library being replaced which fails three of them). In both dimensions this is an improvement over the previous condition. I think you're right that you should have a test suite for your combined markdown format! |
@frasertweedale I don't know enough about Nix to fix the Nix build action. Is that something you could help me with? |
ping @blackheaven |
@frasertweedale The request review is because I think all the changes I'm responsible for are in and I think I'm ready to hand this off to the maintainers to decide what to do with (like implementing a test suite first). If there's other changes on my end, let me know. |
@frasertweedale as a heads-up, I'm working toward what I think is a nice middle ground where the library will expose machine-readable error messages in low-level modules while the top-level Toml module will render out human readable error messages. So I should be able to support both sorts of users in the next release. |
@glguy thank you very much. I'll aim to establish a test suite in the coming week or so. Some other changes are coming that will require a rebase but we can definitely handle that on our side. So, it will probably be some weeks before we land this PR, but there seems to be a consensus to accept this change. So thank you very much for your contribution! |
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.
Thanks, that looks good to me!
PR rebased and adapted for the new |
Oops, I merged the conflicting change, I'll rebase shortly. |
14e167e
to
115e16c
Compare
55e2222
to
7e1216c
Compare
I've rebased this PR on top of the new golden tests, it should be good to go now. Thanks @glguy! |
@frasertweedale may we merge this now? |
7e1216c
to
c8a9258
Compare
I just rebased to validate the tests. |
Sure!
I'm sure you'll take a look yourself to see that the behavior you expect as been preserved, but I'm able to run the tool on the 3 examples we have so far and see it working well.
I've also tested that TOML generation looks to match. The quoted TOML below was generated by the toml-parser library
Note that the only difference is a little more whitespace and everything is alphabetized. If you decide you like certain fields to render before others, you can specify that with prettyTomlOrdered
Of course I'm open to requests for improvements to this PR!