Stabilize Cargo's weak-dep-features and namespaced-features. by ehuss · Pull Req...

Thanks for the ping @ehuss. The only concern I have is regarding support for older versions of cargo. As I understand it, it seems like this would split the ecosystem into 3 tiers:

• Versions of cargo that support "v"=2 entries in the index and can work with all published crates.
• Cargo from 1.51 until this is implemented, which will filter out the "v"=2 entries in the index and cannot see newer crates that use either of these features.
• Cargo versions older than 1.51 will use all entries in the index but ignore the features2 field, resulting in errors or unexpected behavior.

For the last 2 bullet points, the reference section does state "older versions will ignore the "features2" field, allowing them to behave correctly assuming there is a Cargo.lock file (or the packages they need do not use the new syntax)." So maybe it is fine to run cargo update with a newer cargo and then old versions of cargo will work correctly, but I'm not really clear on how that works. Cargo.lock doesn't appear to directly record any data about which features are enabled for each crate, but it will drop a crate from the dependencies array if the crate is optional and not required by any enabled features. However, if the new dependency-name?/feature-name syntax is used, then it seems like a newer version of cargo will correctly include dependency-name in the dependency tree encoded in Cargo.lock such that older versions of cargo will probably include dependency-name in their build, but I don't see how the older version of cargo would know to correctly enable feature-name when building dependency-name.

To provide some data for versions of cargo currently in the wild, I've gone through the last 48 hours of request logs on crates.io (with the vast majority of requests being to the download endpoint). A few notes about the results:

• The major version in the version string was bumped from 0 to 1 in 1.26, so 1.26 and 0.26 are reported in separate rows of the table. I haven't updated the chart to include this, because the data points aren't visible at that scale anyway.
• It appears that rustc 1.55.0-nightly currently ships with cargo 1.54.0-nightly (44456677b 2021-06-12), so the 1.54 results include currently beta and nightly users. The few results for cargo 1.55 are likely to be locally compiled builds.
• Blank user-agent strings (which are only allowed on the crate download endpoint) are way more prevalent than I expected, at nearly 31 million requests in the last 48 hours (nearly 3x all reported cargo versions). It is unclear if this is a bug, or if maybe there is a large org or CI provider sending these requests (via a 3rd party tool, or possibly by setting CARGO_HTTP_USER_AGENT or http.user-agent to the empty string). I did find rust-lang/cargo#8979 which could be related.

In the chart below, I've dropped the blank user agents so that the pattern of known cargo versions is more visible:

As I understand it, 1.47 is the minimum supported rustc version for current Firefox stable. I know that Ubuntu has backported this version to LTS distros for this reason. Strangely, while the deb package is versions as 0.47.0-1~exp1ubuntu1~20.04.1, on an Ubuntu 20.04 LTS system I have, cargo -V reports cargo 1.46.0. I don't know what versions other distros ship, but I'm guessing distro packaging helps explain the spikes at 1.47 and 1.46.

Raw data table