Separate Cargo.toml section for optional dependencies?

tools and infrastructure cargo
1

Just a random thought I had... it seems increasingly common to see people format their Cargo.toml dependencies something like this:

[dependencies]
aaa = "0.0.1"
bbb = "0.1.2"
ccc = "1.2.3"

# Optional dependencies
ddd = { version = "0.0.2", optional = true }
eee = { version = "0.2.3", optional = true }
fff = { version = "2.3.4", optional = true }

What if that were first class instead, by splitting optional dependencies into a separate table ala dev-dependencies?

[dependencies]
aaa = "0.0.1"
bbb = "0.1.2"
ccc = "1.2.3"

[optional-dependencies]
ddd = "0.0.2"
eee = "0.2.3"
fff = "2.3.4"

Might be something interesting to include in a 2021 edition?

1 Like
2

Increasingly, I myself am leaning towards full-tabling more dependencies:

[dependencies.ddd]
package = "ddd"
version = "0.0.2"
optional = true
default-features = false
features = []

because I find myself adding more keys than comfortably fit in an inline table fairly often.

Another think I do is note which optional dependencies are "public features" in the [features] table with comments. E.g.

[features]
default = []

# optional deps
# ddd = [ "crate/ddd" ]
# eee = [ "crate/eee" ]
# fff = [ "crate/fff" ]

I suspect (though have no data to back up) that a motivating reason that people separate optional deps from nonoptional deps is so that it's easier to discover what feature flags are available, and allowing declaration of these features would lower the motivation for splitting them like this.

That's not to say I don't still see a benefit in clearly demarkating optional versus nonoptional dependencies. This is just noting a different potential related cause of the same symptom.

1 Like