Cargo: Feature Request: Ability to disable single default features

[ideasman42]

The current documentation here: http://doc.crates.io/manifest.html states:

With the exception of the default feature, all features are opt-in. To opt out of the default feature, use default-features = false and cherry-pick individual features.

This is quite rigid, since it means you can't make a small adjustment to defaults - where a program may have multiple options which aren't related.

It also means if I use a 3rd party package with modified defaults, after an update I need to check if defaults where added which I might want to enable.

---

Note, I asked this question on stackoverflow, it was suggested to open an issue here:
http://stackoverflow.com/questions/39734321

[alexcrichton]

Yeah it's true that default features are a _very_ weighty decision and are quite difficult to reverse. I don't think we can add the ability to force-disable them, however, because how would we know whether a dependency actually needs the feature or not?

[ideasman42]

@alexcrichton, maybe this is a bigger change then I'd expected, am not very experienced using Cargo.

Could dependencies list features they require?

[alexcrichton]

Dependencies already do, the default feature is just special where it's turned on by default. If a crate has a feature that may be disabled then in general crates shouldn't move it to a default feature.

[ideasman42]

In that case wouldn't it be possible to disable a default - having the same behavior as if you explicitly listed all defaults, without the one(s) which have been requested to be disabled?

[alexcrichton]

Yeah you can disable default features with default-features = false, but Cargo also unions features requested for a crate so if _any_ crate doesn't disable a default feature then it ends up enabled.

[tbu-]

This is a backward-compatiblity hazard. E.g.: It seems that libcore is getting default features, relatively harmless ones, they change some formatting. Some crate today might opt out of default features and only select the float formatting thing. This means that libcore can never add another default feature that disables existing stuff without breaking that crate.

The better way to handle that would be that each crate has a list of default features that it does not require. This way, default features can be added in the future.

[ideasman42]

I don't know about libcore but at an application level - it often makes sense to be able to disable dependencies (which are default since they are used in official release builds).

In for you may want to build FFMPEG with patented codecs or not. You may want to build a video editor with FFMPEG or not.
This is typically the case for file formats, codecs, or optional scripting languages (as VIM has with Python, Ruby, Lua... etc)

[tbu-]

Note that I don't talk about hard-disabling dependency feature, but rather the equivalent of today's default-features = false and then a list of all the other features in the features = [] list. That means if some other dependency pulls in my disabled default feature, I still get it.

[alexcrichton]

@tbu- the idea seems sound to me at least!

[kornelski]

I'd especially like this to work on command line. --no-default-features is lengthy, and requires user to repeat other defaults. A syntax sugar for it would be very helpful.

Here's a proposal:

Features prefixed with - are removed from the set of default features, i.e.:

D = default features
F = user-specified features without - prefix
N = user-specified features with - prefix

Currently:

features = D ∪ F

Proposed:

features = (D ∖ N) ∪ F

e.g. given

[features]
default = ["foo", "bar"]
foo = []
bar = []
quz = []

--features=-bar,quz is desuraged to --no-default-features --features=foo,quz