log 0.4.24 with std feature always adds value-bag to lock file

[zh-jq]

An empty crate with the following dependencies will always pull in a log of dependencies

[dependencies]
log = { version = "0.4", features = ["std"] }

Here is the output when update log from 0.4.22 to 0.4.24:

# cargo update -p log --precise 0.4.24
    Updating crates.io index
      Adding erased-serde v0.4.5
      Adding itoa v1.0.14
    Updating log v0.4.23 -> v0.4.24
      Adding proc-macro2 v1.0.93
      Adding quote v1.0.38
      Adding ryu v1.0.18
      Adding serde v1.0.217
      Adding serde_derive v1.0.217
      Adding serde_fmt v1.0.3
      Adding sval v2.13.2
      Adding sval_buffer v2.13.2
      Adding sval_dynamic v2.13.2
      Adding sval_fmt v2.13.2
      Adding sval_json v2.13.2
      Adding sval_nested v2.13.2
      Adding sval_ref v2.13.2
      Adding sval_serde v2.13.2
      Adding syn v2.0.96
      Adding typeid v1.0.2
      Adding unicode-ident v1.0.14
      Adding value-bag v1.10.0
      Adding value-bag-serde1 v1.10.0
      Adding value-bag-sval2 v1.10.0

[hanna-kruppe]

From what I can tell, it's added to the lockfile due to a Cargo bug (rust-lang/cargo#10801) but not actually built. Still annoying because spurious lockfile entries mislead a lots of helpful tools that rely on parsing the lockfile or the output of cargo metadata.

[KodrAus]

That’s a pretty alarming number of dependencies we don’t actually use. The bloat may be enough to warrant trying to find a workaround here, but I suspect we may be a bit stuck. At least based on that linked issue it looks like we’ve got plenty of company.

[hanna-kruppe]

What would be the downside of reverting back to "compound" features like kv_std? Is it just less convenient/idiomatic or is there useful functionality that can only be provided with the new style? Removing the feature implication again is technically a breaking change for anyone who started relying on it, but if it's done quickly enough (and 0.4.24 is yanked so nothing new starts depending on it) it might be fine for practical purposes.

[KodrAus]

Until we figure this out I've yanked 0.4.24.

The idea here was to start moving away from needing kv_* prefixed features like kv_std in favor of just enabling kv and std. There are other roadblocks to taking it further, but this was a first step.

log isn't the only library affected by this bug, and pushing the burden of working around it back onto libraries isn't moving things forwards. It looks like this is basically stalled on rearchitecting parts of Cargo, but it looks like progress is being made. I don't know when that would likely land though, it's been active for a few years now.

Based on how widely used log is, how dependency-averse its typical user is, and how many spurious dependencies are now reported in the lockfile, I would also be inclined to revert the changes we made to log's Cargo features until the Cargo bug is fixed.