termination feature infects the entire workspace

[nagisa]

Cargo will unify the features across crates, so if you have in your workspace two different crates that depend on ctrlc, one with termination feature enabled and other without, then the binary without it enabled will implicitly get the termination feature enabled for it as well, potentially leading to unintended behaviour.

[Detegr]

This is unfortunate. I don't know how to avoid this other than changing the handling of SIGTERM out from a feature and use a separate handler instead. Any ideas?

[nagisa]

Yeah, I don't believe you can get away by using a cargo feature here and will have to make users of this crate to indicate their preference through API in some shape or form.

[Detegr]

I think resolver = "2" in Cargo.toml fixes this issue nowadays.

[jbg]

I think resolver = "2" in Cargo.toml fixes this issue nowadays.

I don't think that's the case. The new feature resolver avoids unifying features between dev-/build- deps and normal deps, but features are still unified within each type of dep. That is to say, if two crates in the normal dependency tree both depend on ctrlc (with compatible versions), and one sets termination, the same instance of ctrlc with termination enabled will be used by both.