Nom is included in public API
epage opened this issue · comments
This makes upgrading nom or moving away from it a breaking change.
Was looking at switching from nom to winnow to reduce the number of dependencies.
This would drop the total dependency count by 2-3:
winnowis already pulled in viatoml(if enabled)nomhas 2 direct dependencies (one isn't even used bynom, the other is only used by one parser which most people likely don't include).
That's indeed an issue, yes. Thanks for raising this!
I am happy with either, a patch to fix the issue you raised here, or a patch(set) to move from nom to another parser implementation.
That said, I would like to offer you maintainership on this crate, if you want it. I am only passively maintaining this and I had little motivation to drive this crate forward in the past... even my config-rs-ng (https://github.com/matthiasbeyer/config-rs-ng) efforts stalled way too early. So I'd love to share maintainership, or actually even step down from maintaining this crate!
I'm fine doing the change but it is a breaking change and unsure how you feel about doing one so soon after the last...
As for maintainership, I would likely be passive about it as I don't even use this crate. I was making these changes mostly because they are low hanging and this is used by so many people.
If I help out or take over, I would update the crate to conform to all of my other crates so that the incremental overhead of taking care of this crate is dramatically lower.
To achieve that, i would like full privileges so I can make any changes to the github side of this to support the above (e.g. install "apps").
If you do get approval, before tackling all that could you please give me a heads-up with a window / notice of about a week?
I'm planning to wrap up my open PRs this month and the less friction to deal with from rebasing those the easier it'll be to get them resolved 😅