rust
/
rfcs
mirror of https://github.com/rust-lang/rfcs
1
0
Fork 0
Code Issues Releases Wiki Activity

Add a note about the design change of RFC 2906

This commit is contained in:
messense 2022-09-28 08:57:40 +08:00 committed by GitHub
parent 699807cb52
commit 106c2c0906
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
text/2906-cargo-workspace-deduplicate.md
View File

@ -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.