Current feature structure makes configuring no native dependencies difficult

[oeed]

I am attempting diesel_async and have been attempting to use mysql_async with the explicit intention of having no native dependencies. This requires using rustls and flate2 with the rust_backend feature.

This works if directly depending upon mysql_async, but if doing so transitively it becomes awkward for crates like diesel_async to do so given how dependencies are currently configured. I'm not entirely sure what the 'best' solution is here, but for a more in-depth explanation of the issue please see this discussion on diesel_async.

[blackbeam]

@oeed, hi.

Well, I agree with @weiznich that it is preferable to keep library feature space as small as possible.

Also I see no problem with adding some convenience features for end users (not for another libraries that depends on your library). default-rustls is an example of such a feature.

For libraries it seem better to do it like this:
If library A depends on library B, than it sets default-features = false on B and adds B's minimal/required set of features into A's default set of features (for A to successfully compile by default).
So, as a downstream user, by disabling default features on A you also disables all the features of B (and all the features of C if B depends on C the same way, and so on). So now you are in a position where you are able to select all the desired features of all the dependencies.

This is true, that this will bloat downstream user's Cargo.toml, but this seem fair to me if user desires some non-standard configuration.

[oeed]

Yeah I do agree too with keeping feature space small.

The primary issue with default-rustls in my use-case is that it uses flate2/zlib, which still incurs a native dependency. Perhaps default-rustls could instead use flate2/rust_backend? As I would imagine a decent proportion of users opting to rustls are doing so do avoid native dependencies.

[blackbeam]

This seems reasonable. I'll update default-rustls feature.