You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the minimum supported Rust version for nom has been a common theme this year, and has caused issues in a lot of crates. nom was also at the receiving end of that issue (#1435). With #1438 a lot of dependencies are removed from test builds, which should prevent some future issues.
But the problem will appear again if nom still relies on other complex crates. Right now, we bring in minimal-lexical and memchr as dependencies, version_check as build dependency, doc-comment and proptest as dev dependencies. As I have done with the bitslice and regex feature, I will probably move more codes in separate crates, to reduce the blast radius of dependency issues.
I am tempted to go further with that solution, by separating nom into a core crate with the basic types and traits, and specific combinators and parsers into other crates, that would have a different lifecycle. That would bring back some velocity to add more features and change APIs, while keeping the core stable fora longer time.
The text was updated successfully, but these errors were encountered:
the minimum supported Rust version for nom has been a common theme this year, and has caused issues in a lot of crates. nom was also at the receiving end of that issue (#1435). With #1438 a lot of dependencies are removed from test builds, which should prevent some future issues.
But the problem will appear again if nom still relies on other complex crates. Right now, we bring in minimal-lexical and memchr as dependencies, version_check as build dependency, doc-comment and proptest as dev dependencies. As I have done with the bitslice and regex feature, I will probably move more codes in separate crates, to reduce the blast radius of dependency issues.
I am tempted to go further with that solution, by separating nom into a core crate with the basic types and traits, and specific combinators and parsers into other crates, that would have a different lifecycle. That would bring back some velocity to add more features and change APIs, while keeping the core stable fora longer time.
The text was updated successfully, but these errors were encountered: