supporting range of breaking change versions for tokio-rustls causes dependency hell

[TheButlah]

The use of >=0.25.0,<0.27 in the versioning for tokio-rustls is causing dependency hell. While well intentioned, the issue is that cargo doesnt provide a way to choose which version of tokio-rustls will be chosen for users of tls-listener. Even if downstream users use the reexported tokio-rustls from tls-listener, its not actually safe/possible to do this, because the two tokio-rustls versions have breaking changes. So depending on which apis are needed, we can't actually use the re-export.

For example, suppose I need install_default(), there is no way to force tls-listener to use the correct matching tokio-rustls, and by extension rustls, version.

Conceptually this is because re-exporting tokio-rustls means that this crate has breaking changes depending on whether tokio-rustls 0.25 or 0.26 is chosen by the dependency resolver algorithm.

I suggest releasing a new major version of tls-listener that either:

• Continues the re-export and uses only one major version for tokio-rustls (0.26)
• Has two dependencies both of which are optional and controlled by feature flags: tokio-rustls-025 and tokio-rustls-026. Each should be re-exported as differently named exports. Note: its important that both the tokio-rustls-025 and tokio-rustls-026 feature flags can be provided at the same time, without any breaking changes, feature flags cannot be mutually exclusive.

As an example of how this can manifest in real world scenarios, see eclipse-zenoh/zenoh#1747

[tmccombs]

Explicitly specifying the version of tokio-rustls in the parent crate doesn't work?

[TheButlah]

Nope! You might get lucky and cargo's dependency resolver will have tls-transport depend on tokio-rustls 0.26, or you might get unlucky and cargo will still use 0.25 for tokio-rustls. Try taking https://github.com/TheButlah/bugs/tree/thebutlah/zenoh-rustls-mismatch and adding tokio-rustls = { verison = "0.26, default-features = false}. It still errors.

The only way to fix it is to allow someone to do feature flags to explicitly control which rustls version tls-listener is going to use, or to remove the ambiguity in major versions.

[TheButlah]

Here, I've created an even more minimal reproducible example:
TheButlah/bugs#3

[tmccombs]

Huh. That seems like it is probably a bug in cargo's resolver. Have you reported it to cargo yet?

[TheButlah]

That seems like it is probably a bug in cargo's resolver

Haven't reached out, but I'm pretty sure that this is expected behavior. tls-listener explicitly opts into supporting either version. There is no reason cargo shouldn't be free to choose 0.25.

Another way to look at it: what if I had a binary that needed both traits from 0.25 implemented (for example to be able to use a different crate that needs those traits) and the 0.26 behavior (for example to be able to use get_default from rustls)? Its not possible right now.

If tls-listener wants to support both 0.25 and 0.26, it needs to use feature flags. Or instead, it should choose only one.