Shared dependencies and incompatible features


#1

Hi,

I’m struggling with a dependency problem in my crate, that I’m hoping you guys can help me with:

I’m trying to use bindgen (0.32.1) and config (0.7.0) and both in turn depend (either directly or indirectly) on nom (3.2.1). The problem is that one of the them requires the nom feature “verbose-errors” but that causes a compile error in the other: https://thepasteb.in/p/P1hvXjjPOxNil

Is there anyway to work around this?

In my case, bindgen is a build-dependency while config is a regular dep so a theoretical solution would be to build nom seperately for the different class of dependencies. But is that even possible?

Thanks!


#2

The best solution is probably to make an issue/PR to one of the dependencies and ask them to add a feature flag which will toggle whether the verbose-errors feature is activated for nom. That way users can toggle how nom’s error handling to make sure all crates work together.

I can’t really think of any other way to work around it :disappointed: The root problem is that feature flags are meant to be a purely additive thing, and nom seems to have broken that contract. Enabling a feature should only add functionality, not change behaviour or signatures.


#3

Author of cexpr here (bindgen’s dependency that uses nom). This is a real bummer. What makes the situation even worse is that a crate’s dependents can’t figure out which feature is currently enabled, so it’s not possible to conditionally generate code for one path or the other.

I filed a PR with config to be compatible with either feature configuration: https://github.com/mehcode/config-rs/pull/58


#4

Thank you @jethrogb! Really appreciate it.

I’m using your PR in my Cargo.toml and now it builds fine! Hopefully it gets merged soon.


#5

How do you use individual PR in Cargo.toml?


#6

You usually add a [patch] section to your Cargo.toml to override a dependency.


#7

In my case I just did:

config = {git = “https://github.com/jethrogb/config-rs.git”, rev = “97b9687”}

But using a patch section is probably a more correct way to do it :slight_smile: