Conversation
|
r? @weihanglo rustbot has assigned @weihanglo. Use |
| match manifest_path.is_file() { | ||
| true => {} |
There was a problem hiding this comment.
Cleaned up in the next commit
| // TODO: remove once frontmatter hits nightly | ||
| if unit.pkg.manifest().is_embedded() { |
There was a problem hiding this comment.
Blocked on rust-lang/rust#148051 hitting nightly
| // TODO: remove once frontmatter hits nightly | ||
| if unit.pkg.manifest().is_embedded() { |
There was a problem hiding this comment.
Blocked on rust-lang/rust#148051 hitting nightly
|
@rfcbot fcp merge T-cargo For me, my biggest concerns are the first two Risks listed. |
|
Team member @epage has proposed to merge this. The next step is review by the rest of the tagged team members: Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
There was a problem hiding this comment.
Should we inform rustfmt team that we're going to stabilize this and leave frontmatter style issue unresolved? I remembered that let-else has caused confusions and frustrations when we stabilized it in the language syntax side but rustfmt didn't format it: rust-lang/rustfmt#4914.
At least the rustfmt team should be aware of the potential incoming volume of issues regarding this.
| in the [TOML] format. It contains metadata that is needed to compile the package. Checkout | ||
| the `cargo locate-project` section for more detail on how cargo finds the manifest file. | ||
|
|
||
| The content of the manifest can also be embedded inside of the frontmatter inside of a Rust source file: |
There was a problem hiding this comment.
Not a blocker but not satisfied with the current stable doc. I would love to see a dedicated section for Cargo scripts with some examples, and all other mentions of "script" to link back to that section. Currently it is a bit not obvious when it is mentioned.
The original unstable docs has some good stuff in it but maybe it depends on many stuff we want to commit as "stable"
(Or it was migrated to elsewhere? The diff is too large that I could have missed it)
There was a problem hiding this comment.
Was unsure how to handle it. A guide? If so, where does it fit in. A reference? Does it get its own page or a section on manifests?
There was a problem hiding this comment.
Or a reference-like doc in src/doc/man/cargo.md, and we have another standalone guide? In manifest is not too bad but script is more than manifest.
All these teams actually |
This is worth calling out in user doc that whether the target directory of script is considered implementation details. |
This was handled as part of the Frontmatter stabilization. |
| in the [TOML] format. It contains metadata that is needed to compile the package. Checkout | ||
| the `cargo locate-project` section for more detail on how cargo finds the manifest file. | ||
|
|
||
| The content of the manifest can also be embedded inside of the frontmatter inside of a Rust source file: |
There was a problem hiding this comment.
Or a reference-like doc in src/doc/man/cargo.md, and we have another standalone guide? In manifest is not too bad but script is more than manifest.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| } | ||
|
|
||
| #[cargo_test(nightly, reason = "-Zscript is unstable")] | ||
| #[cargo_test(nightly, reason = "`#[feature(frontmatter]` hasn't hit stable yet")] |
There was a problem hiding this comment.
That attribute seems typoed throughout, shouldn't it be:
| #[cargo_test(nightly, reason = "`#[feature(frontmatter]` hasn't hit stable yet")] | |
| #[cargo_test(nightly, reason = "`#![feature(frontmatter)]` hasn't hit stable yet")] |
This comment has been minimized.
This comment has been minimized.
|
|
||
| `cargo` _script_ operate on system or user level, not project level. | ||
| This means that the local [configuration discovery] is ignored. | ||
| Instead, the configuration discovery begins at `$CARGO_HOME/config.toml`. |
There was a problem hiding this comment.
Is this documentation outdated? If I'm interpreting #16620 correctly, Cargo will read config.toml from $SCRIPT_FILE_DIRECTORY/config.toml, or am I misreading that PR?
The comment in that PR notes that it operates like cargo install --path, which I think means these docs should say what that does? (https://doc.rust-lang.org/nightly/cargo/commands/cargo-install.html#configuration-discovery)
There was a problem hiding this comment.
Thanks. This has gone through several changes and I forgot to make sure this aligned with the latest version.
|
I should have done this earlier. I think there are some concerns that are worth addressing before merging. The concern about edition behavior is described in rust-lang/rust#152254. @rfcbot concern edition-behavior Additionally, I think there is a security concern that we should take very seriously. The interaction of cargo-script with RFC#3279 could make it very easy to expose a user to dangerous behavior. This is also described somewhat in rust-lang/rust#152254. @rfcbot concern security |
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (possibly #16851) made this pull request unmergeable. Please resolve the merge conflicts. |
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
View all comments
Fixes #12207
RFC: https://rust-lang.github.io/rfcs/3502-cargo-script.html
Tracking issue: #12207
Frontmatter stabilization: rust-lang/rust#148051
This stabilizes an MVP of Cargo script
.rsextensionCargo.tomlpackage.nameis optional, defaults to the file stempackage.editiondefaults to current edition, not 2015 edition, with a warningpackage.build,package.links,package.default-run,package.workspace,package.auto-*are disallowedworkspace,build-dependencies, and any build-target tables are disallowedpackage.namedefaulting logicpackageUnicodeXIDcharacters with-or_contestselfdepscargo fooprecedence:.rsextension or a path component is present (e.g../foo)cargo installerrors on publishing a scriptcargo packageerrors on publishing a scriptcargo publisherrors on publishing a scriptarg0is set on a best-effort basis to the script's pathCARGO_MANIFEST_PATHwas previously stabilized in addition to the existingCARGO_MANIFEST_DIRcargo foo.rsloads config relative tofoocargo install --path bar/and unlike the rest of the Cargo commandscargo run --manifest-path foo.rsloads from current dirWhats missing:
Known issues:
cargo removeprints the "unset edition" warning twice#!and[]and not commentsbuild-dir. Garbage collect wholetarget/#13136 will resolve this.Risks
If people share their(fix(script): Make the lockfile script-specific independent of build-dir #16619)build-diracross projects, then multiple scripts will point to the sameCargo.lock, fighting over what is locked in itNot allowing local config for scripts could become a problem as we get into workspace support as people would expect their repo's config to be respected when it won't be(fix(script): Load config relative to the script #16620)cargo fooPATHthat makes this not workFuture possibilities
target/#13136)package.nameoptional #12689cargo Cargo.tomlsupport