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

Unable to use a feature of an optional dependency from a feature #3494

Closed
EpicatSupercell opened this issue Jan 4, 2017 · 12 comments · Fixed by #8818
Closed

Unable to use a feature of an optional dependency from a feature #3494

EpicatSupercell opened this issue Jan 4, 2017 · 12 comments · Fixed by #8818
Assignees
Labels
A-features Area: features — conditional compilation C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`

Comments

@EpicatSupercell
Copy link

For example lets say we use

[dependencies.serde]
version = "0.8.*"
optional = true
default-features = false

and we want to use the std feature of serde if it is used.

[features]
std = ["serde/std"]

But now if someone wants to use our std feature serde WILL be imported. If I would want to represent this I would write

[features]
std = ["serde", "serde/std"]

Right now it's impossible to use a feature of an optional dependency from an own feature without forcing it to be used.

@EpicatSupercell EpicatSupercell changed the title Unable to use a feature of an optional dependency Unable to use a feature of an optional dependency from a feature Jan 4, 2017
@alexcrichton
Copy link
Member

Yes it's true that relying on a/b will implicitly activate the dependency on a, rather than just activating the b feature in a if a is already activated. I don't believe it's possible to express what you're thinking here today with Cargo features.

@alexcrichton alexcrichton added the A-features Area: features — conditional compilation label Jan 5, 2017
@valarauca
Copy link

To chime in.

There is a push in slog to move to opaque key value pairs, so that keys can be variable when the same logging function is invoked.

Anyways. Since the new type definition is feature gated by slog, any project that imports slog, and feature gates this new feature, can't optionally trigger this feature gate in slog.

@kvark
Copy link

kvark commented Aug 19, 2019

Just a friendly heads up from #7259 - this problem is hitting gfx-rs ecosystem quite badly. We want things like serde and winit to be transparently enabled for the backends that the user selects, not all the things in the universe.

@RalfJung
Copy link
Member

libstd itself also hit an annoying instance of this.

@RalfJung
Copy link
Member

Over in #7259, @est31 proposed the following backwards-compatible syntax for "enable this feature of that dependency only if the dependency is otherwise enabled": "foo" = ["?bar/foo"]. The syntax bikeshed aside, I think it would be great to have this feature available somehow; this is bound to come up whenever features get exposed recursively (such as whether backtrace depends on backtrace-sys, or the serde/winit feature in gfx-rs).

snejugal added a commit to tbot-rs/tbot that referenced this issue Mar 30, 2020
When we introduced the `rustls` feature, we did it like this:

```toml
[features]
proxy = ["hyper-proxy"]
rustls = ["hyper-proxy/rustls", "tokio-rustls", "hyper-rustls"]
tls = ["hyper-proxy/tls", "native-tls", "tokio-tls", "hyper-tls"]
```

A problem is hidden here: enabling an optional dependency's feature
enabled the dependency. Because of this, `hyper-proxy` is already being
downloaded and compiled, even if `proxy` isn't enabled:

```
$ cargo c
             …
    Checking hyper-proxy v0.6.0
    Checking tbot v0.5.1 (…)
```

But to be able to use it, you have to enable the `proxy` feature, which seems
odd. Since cargo doesn't provide a way to enable an optional dependency's
feature without enabling the dependency (at least yet; rust-lang/cargo#3494),
I think that it's better to always provide proxy functionality.
@xu-cheng
Copy link

xu-cheng commented Apr 8, 2020

Just my 2 cents. Alternatively, this could be solved if the following syntax is supported. The same syntax will also address #1839.

[features]
default = ["std"]
std = []

[target.'cfg(feature = "std")'.dependencies]
serde = { version = "*", optional = true }

[target.'cfg(not(feature = "std"))'.dependencies]
serde = { version = "*", optional = true, default-features = false }

dvdplm pushed a commit to paritytech/parity-common that referenced this issue May 4, 2020
* primitive-types: add no_std support for serde feature

This adds no_std support to primitive-types with serde.

Due to rust-lang/cargo#3494,
a separate new feature `serde_no_std` is created.

* primitive-types: update changelog

* travis: add tests for primitive-types
zakarumych added a commit to arcana-engine/goods that referenced this issue Jun 16, 2020
This enables serde crates themselves.
Related cargo issue: rust-lang/cargo#3494
zakarumych added a commit to arcana-engine/goods that referenced this issue Jun 16, 2020
This enables serde crates themselves.
Related cargo issue: rust-lang/cargo#3494
alecmocatta added a commit to constellation-rs/amadeus that referenced this issue Jul 13, 2020
alecmocatta added a commit to constellation-rs/amadeus that referenced this issue Jul 14, 2020
@joshtriplett
Copy link
Member

joshtriplett commented Aug 18, 2020

I just ran into this myself, and would like to see a solution as well.

@xu-cheng I would love to see that syntax work.

@RalfJung
Copy link
Member

RalfJung commented Aug 18, 2020

That syntax feels rather verbose for what I think is the common case ("crate/feature but only if crate is enabled as a dependency). In particular that syntax will lead to combinatorial explosion when there are several feature being forwarded:

[features]
default = ["std"]
std = ["?create/std"]
serde = ["?create/serde"]

Now we need to specify the crate dependency 4 times, for the 4 combinations of whether std and serde are enabled or not.

@cdisselkoen
Copy link

Just ran into this issue as well. FWIW, I think the ["?crate/feature"] syntax looks good.

@tarcieri
Copy link

Seems I opened a "Pre-Pre-RFC" thread about this same problem:

https://internals.rust-lang.org/t/pre-pre-rfc-weak-cargo-feature-activation/13141/1

I also like the ["?crate/feature"] syntax.

@cdisselkoen
Copy link

thanks @ehuss for getting the ball rolling on this!

@est31
Copy link
Member

est31 commented Nov 5, 2020

Tracking issue: #8832

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-features Area: features — conditional compilation C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`
Projects
None yet
Development

Successfully merging a pull request may close this issue.