Deployment timeline of cargo target-specific dependencies

1

RFC 1361 allows specifying dependencies like this:

[target."cfg(windows)".dependencies]
winapi = "0.2"

[target."cfg(unix)".dependencies]
unix-socket = "0.4"

[target.'cfg(target_os = "macos")'.dependencies]
core-foundation = "0.2"

The RFC did not specify a timeline for the community to shift over to using these kinds of dependencies. The problem is that old cargo versions will not be able to interpret the new targets correctly. Ironically, support for this was implemented in 0.9.0 but the toml version needed to support this was not configured in cargo until 0.10.0. To clarify compatibility:

  • target.x86_64-pc-windows-msvc.dependencies
  • cargo 0.8.0-: supported
  • cargo 0.9.0: supported
  • cargo 0.10.0+: supported
  • target."cfg(windows)".dependencies
  • cargo 0.8.0-: ignored
  • cargo 0.9.0: supported
  • cargo 0.10.0+: supported
  • target.'cfg(target_os="windows")'.dependencies
  • cargo 0.8.0-: Cargo.toml parse error
  • cargo 0.9.0: Cargo.toml parse error
  • cargo 0.10.0+: supported

I’m not sure this is accurate, but I believe the latest stable Rust (1.9.0) shipped with cargo 0.10.0.

So, while moving some of the big crates over might cause breakage, I’d really like to get rid of the winapi dependency in all of my crates. Would the Rust 1.10.0 release be a good time to switch everything over?

P.S. Man I wrote this whole post being sure rand depended on winapi but that’s no longer the case. Regardless, there are still plenty of crates that could benefit from winapi-abatement: cargo, mio, openssl, time, etc. winapi is still the 2nd most-downloaded crate on crates.io.

2

Oh oops, I thought those were supposed to be coordinated when they went out… Not entirely sure what happened!

Note though that the toml-rs fix was purely to support [foo.'bar'.baz], previous versions all supported [foo."bar".baz] (note the double vs single quotes). Along those lines Cargo 0.9.0 (released with Rust 1.8.0) should have support for target-specific dependencies with this syntax so long as you use double quotes.

When you update to use this syntax is kinda up to you as well depending on how many historical versions of Rust you’d like to support.

3

Perhaps I should clarify, none of my crates depend directly on winapi but there are many “core ecosystem” crates that do, including some managed by the Rust project. I was hoping to establish a timeline for those crates.

4

Ah I see, that would probably best be decided by RFC 1619 which spells out a story for Rust compatibility for nursery crates, which is also likely to be a more broadly accepted policy for crates in general.

5

Ah, perfect, the proposed language there seems directly applicable to this question as well.

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.