Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more optional features to the main futures crate #1875

Closed
seanmonstar opened this issue Sep 17, 2019 · 5 comments
Closed

Add more optional features to the main futures crate #1875

seanmonstar opened this issue Sep 17, 2019 · 5 comments

Comments

@seanmonstar
Copy link
Contributor

seanmonstar commented Sep 17, 2019

For convenience, the futures (well, futures-preview for now) crate re-exports from all of the futures-*. This can be a nice first experience, being able to use streams, sinks, channels, and what-not out-of-the-box. However, due to this, other libraries have been removing their dependency on futures to a smaller group that they need (such as futures-core and futures-util).

I think it could be useful if a library could depend on futures while disabling the pieces they don't need. So, like in hyper, it could have futures = { version = "0.3", default-features = false, features = ["util"] }.

@Pauan
Copy link

Pauan commented Sep 17, 2019

Unfortunately, that doesn't work. Imagine you have this crate layout:

    futures
 /          \
A            B
 \          /
      C

Let's suppose that crate A uses default-features = false, but crate B does not.

In that case all of the default features will be enabled, and there is nothing crates A or C can do about it.

Some more context here.

@Nemo157
Copy link
Member

Nemo157 commented Sep 17, 2019

That’s absolutely fine, if A only needs some limited subset of features but B needs them all then that is features working as intended. If B doesn’t need them all then that indicates that there needs to be more understanding in the ecosystem that default-features = false should be the default stance you take to all dependencies, and just activate what features you need.

@Pauan
Copy link

Pauan commented Sep 17, 2019

@Nemo157 If B doesn’t need them all then that indicates that there needs to be more understanding in the ecosystem that default-features = false should be the default stance you take to all dependencies, and just activate what features you need.

Yes, that's exactly the problem. Every crate would need to use default-features = false and only enable the features they want. Even a single crate messing it up will affect every other crate.

Unfortunately, it's far too easy to mess up default-features and forget to use it. That problem doesn't happen nearly as much with separate crates (where there is a clear implicit understanding that an umbrella crate pulls in everything).

So, as an alternative suggestion, what if nothing was enabled by default in futures, and you had to selectively enable individual features. Then there would be an all feature which enables all the other features:

[dependencies]
util = { version = "0.3.0", optional = true, package = "futures-util" }
core = { version = "0.3.0", optional = true, package = "futures-core" }
executor = { version = "0.3.0", optional = true, package = "futures-executor" }

[features]
all = ["core", "util", "executor"]

This means you don't need to use default-features = false (which avoids all the issues with it), and it makes it impossible to screw up: you cannot accidentally enable all features.

@taiki-e
Copy link
Member

taiki-e commented Jun 5, 2020

features = ["util"]

FYI: It is impossible to add the "util" feature with the current crate-layout (because the std and alloc features cannot be properly propagated).
To separate "util" by a feature flag, it needs to merge futures and futures-util, and implement auto-detection based no-std support for most sub crates (or merge most sub crates).

@taiki-e taiki-e modified the milestones: 0.3 release, futures-0.4 Dec 17, 2020
@taiki-e taiki-e added S-needs-api-design Status: Before implementing this, a discussion or decision on the new API is needed. S-needs-decision Status: A decision on whether or not to do this is needed. labels Jul 19, 2023
@taiki-e
Copy link
Member

taiki-e commented Jul 20, 2023

Closing in favor of #2295.

@taiki-e taiki-e closed this as completed Jul 20, 2023
@taiki-e taiki-e removed S-needs-api-design Status: Before implementing this, a discussion or decision on the new API is needed. S-needs-decision Status: A decision on whether or not to do this is needed. labels Jul 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants