From 106c2c0906424753f2bff0063a711d598f08d1fa Mon Sep 17 00:00:00 2001 From: messense Date: Wed, 28 Sep 2022 08:57:40 +0800 Subject: [PATCH] Add a note about the design change of RFC 2906 --- text/2906-cargo-workspace-deduplicate.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/text/2906-cargo-workspace-deduplicate.md b/text/2906-cargo-workspace-deduplicate.md index f4bb23ff4..7a1b948fc 100644 --- a/text/2906-cargo-workspace-deduplicate.md +++ b/text/2906-cargo-workspace-deduplicate.md @@ -3,6 +3,8 @@ - RFC PR: [rust-lang/rfcs#2906](https://github.com/rust-lang/rfcs/pull/2906) - Rust Issue: [rust-lang/cargo#8415](https://github.com/rust-lang/cargo/issues/8415) +> **Note**: This feature was stabilized in Rust 1.64. Several design changes were made in the course of the implementation. Please see the documentation for [`[workspace.package]`](https://doc.rust-lang.org/nightly/cargo/reference/workspaces.html#the-package-table) and [`[workspace.dependencies]`](https://doc.rust-lang.org/nightly/cargo/reference/workspaces.html#the-dependencies-table) for details on how to use this feature. + # Summary [summary]: #summary @@ -180,10 +182,10 @@ version = { workspace = true } This directive tells Cargo that the version of `foo` is the same as the `workspace.version` directive found in the workspace manifest. This means that in addition to a new `[workspace.dependencies]` section, package metadata keys -can now also be defined inside of a `[workspace.package]` section: +can now also be defined inside of a `[workspace]` section: ```toml -[workspace.package] +[workspace] version = "0.25.2" ``` @@ -233,11 +235,11 @@ Dependencies declared in `[workspace.dependencies]` have no meaning as-is. They do not affect the build nor do they force packages to depend on those dependencies. This part comes later below. -The `[workspace.package]` section will also allow the definition of a number of keys +The `[workspace]` section will also allow the definition of a number of keys also defined in `[package]` today, namely: ```toml -[workspace.package] +[workspace] version = "1.2.3" authors = ["Nice Folks"] description = "..." @@ -252,11 +254,11 @@ categories = ["development-tools"] publish = false edition = "2018" -[workspace.package.badges] +[workspace.badges] # ... ``` -Each of these keys have no meaning in a `[workspace.package]` table yet, but will have +Each of these keys have no meaning in a `[workspace]` table yet, but will have meaning when they're assigned to crates internally. That part comes later though in this design! Note that the format and accepted values for these keys are the same as the `[package]` section of `Cargo.toml`. @@ -294,7 +296,7 @@ This directive indicates that the license of `foo` is the same as `workspace.license`. If `workspace.license` isn't defined then this generates an error. -The following keys in `[package]` can be inherited from `[workspace.package]` with the +The following keys in `[package]` can be inherited from `[workspace]` with the new `workspace = true` directive. ```toml @@ -589,7 +591,7 @@ ways this could happen. ## Inheriting metadata from other packages One possible extension of this RFC is for metadata to not only be inheritable -from the `[workspace.package]` table but also from other packages. For example a +from the `[workspace]` table but also from other packages. For example a scenario seen in the wild is that some repositories have multiple "cliques" of crates which are all versioned as a unit. In this scenario one "clique" can have its version directives deduplicated with this proposal, but not multiple ones.