Nom is included in public API

[epage]

See ConfigError::ParsePath.

This makes upgrading nom or moving away from it a breaking change.

[epage]

Was looking at switching from nom to winnow to reduce the number of dependencies.

This would drop the total dependency count by 2-3:

• winnow is already pulled in via toml (if enabled)
• nom has 2 direct dependencies (one isn't even used by nom, the other is only used by one parser which most people likely don't include).

[matthiasbeyer]

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!

[epage]

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.

[epage]

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").

[matthiasbeyer]

I do not even have full access myself, so for that we would need to talk to @mehcode ... I hope they respond. In any case, if @epage wants to take over, I'd be fine with it and 👍

[polarathene]

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 😅

[zaneduffield]

Hopefully as part of this change, the Display implementation for ConfigError::ParseParse can be improved.

Currently, it just prints the description of the inner error which is often quite useless

config-rs/src/error.rs

Line 190 in 51acc67

ConfigError::PathParse(ref kind) => write!(f, "{}", kind.description()),

As an example, if you try to parse the path a..b then the error message you get is just

Char

I feel like it should at least tell you that it was an error in parsing the path.

[epage]

Is the concern just with the nom error or errors in general?

[zaneduffield]

Just the Nom error. The other errors I've seen are succinct and informative.