Unused optional dependencies cause "links" conflicts

[kornelski]

[package]
name = "foo"
version = "0.1.0"

[dependencies]
libz-sys = { version = "1.0.25", optional = true }
cloudflare-zlib-sys = { version = "0.1", optional = true }

Both libz-sys and cloudflare-zlib-sys contain links = "z", because they do link to a (fork of) libz with the same global C symbols.

I would like user of the "foo" crate to be able to enable either one of these crates providing "z", and have a links conflict only if both crates accidentally get enabled at the same time.

Unfortunately, it looks like Cargo is resolving links for all crates, even unused ones, without observing whether they are optional.

error: failed to select a version for cloudflare-zlib-sys.
... required by package foo v0.1.0
versions that meet the requirements ^0.1 are: 0.1.2, 0.1.1, 0.1.0

the package cloudflare-zlib-sys links to the native library z, but it conflicts with a previous package which links to z as well:
package libz-sys v1.0.25
... which is depended on by foo v0.1.0

[Eh2406]

Yes indeed, technically features are supposed to be additive, so this is intended. Changing this would mean for example that your lockfile would have to be rebuilt each time you change the features you are testing. In practice, mutually exclusive features exist and need better workflows.

Unintuitively, if you have a library like yours in your dependency tree, then we only check the Links attribute of the activated features. So a currently used workaround is to move the tests to a test project that depends on your project with the selected features. I spell how to set this up better hear.

There is discussion of adding a --minimal-cargo-lock that would provide a way to test only one of the features at a time. (you would need to run the tests twice once with each feature) And so not need a separate test project.

cc previous conversation at #5969

[kornelski]

I see my case is a dupe, so I'll close this