My project consists of several crates, all of them supports more than one async runtime.
So, until now, I used to name my feature flags like this:
tokio-rt, smol-rt, async-rt
The problem is, all projects are in a monorepo, and I have one create with all tests. For some reason, I can't use same feature flags names like the ones above on monorepo crates without have a lot of conflicts.
How did you guys has been managing this kind of issue? I'm considering rename feature flags from tokio-rt to my-crate-tokio-rt, but not sure if I'm going though right direction.
Is anyone here faced this kind of issue before? How have you fixed this?
I'm failing to see how using the same name for features in a monorepo would lead to conflicts. Can you provide examples Cargo.toml files and the resulting error messages?
If the problem is that you want to be able to, from the command line, enable a feature of one of your packages rather than all of your packages that use the same feature name, then you can do that by specifying the package and a / before the feature name:
Yeah, I might be ending up doing this way, everytime when I ommit the crate-name/ I endup seeing a lot build issues with compiler mixing code with feature flags which should be disabled, and trust me, I check and double check default feature flags all the time across all crates to make sure they are the same.
This doesn’t help with your goal of testing features, but in general, if a combination of features causes build failure then that is a flaw in the design of the features. Features are supposed to be “additive”: enabling a feature should not interfere with the use of the library by a dependent that doesn't enable that feature (and a build failure is the worst form of such interference). This is important to ensure that libraries continue to work even when used many times in complex dependency graphs.
Ideally, a feature does not change the behavior of the libraty at all, but only compiles additional code to add more functionality that may be used by the dependent code.
You is right on first sentence, since Tokio and Smol has similar structs, like TcpStream, I used to have feature flags in a exclusive way, not additive.
But it is hard to say a lib which can support two or more different async runtimes can work in additive way, but let's see.