Skip to content

Commit b0d4f6d

Browse files
epagetraviscrossnikomatsakis
authored
Officially recognize carry over of cargo script (#294)
* Officially recognize carry over of cargo script This was approved for 2025h2 and I figured I wouldn't bother carrying it over since so little was left but what was left was the cross-team stuff and I should have called this out. So this is rectifying that. * fix: Remove T-lang design meeting Co-authored-by: Travis Cross <[email protected]> * Apply suggestions from code review --------- Co-authored-by: Travis Cross <[email protected]> Co-authored-by: Niko Matsakis <[email protected]>
1 parent 49b4252 commit b0d4f6d

File tree

1 file changed

+106
-0
lines changed

1 file changed

+106
-0
lines changed

‎src/2025h1/cargo-script.md

Lines changed: 106 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,106 @@
1+
# Stabilize cargo-script
2+
3+
| Metadata | |
4+
|:-----------------|----------------------------------------------------------------------------------|
5+
| Point of contact | @epage |
6+
| Teams | <!-- TEAMS WITH ASKS --> |
7+
| Task owners | <!-- TASK OWNERS --> |
8+
| Status | Proposed |
9+
| Tracking issue | [rust-lang/rust-project-goals#119] |
10+
| Zulip channel | N/A (an existing stream can be re-used or new streams can be created on request) |
11+
12+
## Summary
13+
14+
Stabilize support for "cargo script", the ability to have a single file that contains both Rust code and a `Cargo.toml`.
15+
16+
## Motivation
17+
18+
Being able to have a Cargo package in a single file can reduce friction in development and communication,
19+
improving bug reports, educational material, prototyping, and development of small utilities.
20+
21+
### The status quo
22+
23+
Today, at minimum a Cargo package is at least two files (`Cargo.toml` and either `main.rs` or `lib.rs`).
24+
The `Cargo.toml` has several required fields.
25+
26+
To share this in a bug report, people resort to
27+
- Creating a repo and sharing it
28+
- A shell script that cats out to multiple files
29+
- Manually specifying each file
30+
- Under-specifying the reproduction case (likely the most common due to being the eaisest)
31+
32+
To create a utility, a developer will need to run `cargo new`, update the
33+
`Cargo.toml` and `main.rs`, and decide on a strategy to run this (e.g. a shell
34+
script in the path that calls `cargo run --manifest-path ...`).
35+
36+
### The next 6 months
37+
38+
The support is already implemented on nightly.
39+
The goal is to stabilize support.
40+
With [RFC #3502] and [RFC #3503] approved, the next steps are being tracked in [rust-lang/cargo#12207].
41+
42+
At a high-level, this is
43+
- Add support to the compiler for the frontmatter syntax
44+
- Add support in Cargo for scripts as a "source"
45+
- Polish
46+
47+
### The "shiny future" we are working towards
48+
49+
## Design axioms
50+
51+
- In the trivial case, there should be no boilerplate. The boilerplate should scale with the application's complexity.
52+
- A script with a couple of dependencies should feel pleasant to develop without copy/pasting or scaffolding generators.
53+
- We don't need to support everything that exists today because we have multi-file packages.
54+
55+
## Ownership and team asks
56+
57+
Tracking issue [cargo#12207](https://github.com/rust-lang/cargo/issues/12207):
58+
59+
| Task | Owner(s) or team(s) | Notes |
60+
|------------------------------|---------------------|-------|
61+
| Discussion and moral support | ![Team][] [cargo], [compiler] | |
62+
| Ensure Cargo implementation | @epage | |
63+
64+
### Implement language feature `frontmatter`
65+
66+
Tracking issue [#136889](https://github.com/rust-lang/rust/issues/136889):
67+
68+
| Task | Owner(s) or team(s) | Notes |
69+
|-----------------------------------|------------------------------------|-------|
70+
| Rustc implementation | @epage | |
71+
| Rust-analyzer implementation | @epage | |
72+
| Standard reviews | ![Team][] [compiler] | |
73+
| Lang-team champion | ![Team][] [lang] | @joshtriplett |
74+
| Author call for testing blog post | @epage | |
75+
76+
### Stabilize language feature `frontmatter`
77+
78+
| Task | Owner(s) or team(s) | Notes |
79+
|--------------------------------|------------------------------------|-------|
80+
| Author specification 1st draft | @epage | |
81+
| Finalize specification text | ![Team][] [spec] | @ehuss |
82+
| Lang-team champion | ![Team][] [lang] | @joshtriplett |
83+
| Author stabilization report | @epage | |
84+
| Author stabilization PR | @epage | |
85+
| Stabilization decision | ![Team][] [lang] | |
86+
87+
### Definitions
88+
89+
For definitions for terms used above, see the [About > Team Asks](https://rust-lang.github.io/rust-project-goals/about/team_asks.html) page.
90+
91+
* *Discussion and moral support* is the lowest level offering, basically committing the team to nothing but good vibes and general support for this endeavor.
92+
* *Author RFC* and *Implementation* means actually writing the code, document, whatever.
93+
* *Design meeting* means holding a synchronous meeting to review a proposal and provide feedback (no decision expected).
94+
* *RFC decisions* means reviewing an RFC and deciding whether to accept.
95+
* *Org decisions* means reaching a decision on an organizational or policy matter.
96+
* *Secondary review* of an RFC means that the team is "tangentially" involved in the RFC and should be expected to briefly review.
97+
* *Stabilizations* means reviewing a stabilization and report and deciding whether to stabilize.
98+
* *Standard reviews* refers to reviews for PRs against the repository; these PRs are not expected to be unduly large or complicated.
99+
* *Prioritized nominations* refers to prioritized lang-team response to nominated issues, with the expectation that there will be *some* response from the next weekly triage meeting.
100+
* *Dedicated review* means identifying an individual (or group of individuals) who will review the changes, as they're expected to require significant context.
101+
* Other kinds of decisions:
102+
* [Lang team experiments](https://lang-team.rust-lang.org/how_to/experiment.html) are used to add nightly features that do not yet have an RFC. They are limited to trusted contributors and are used to resolve design details such that an RFC can be written.
103+
* Compiler [Major Change Proposal (MCP)](https://forge.rust-lang.org/compiler/mcp.html) is used to propose a 'larger than average' change and get feedback from the compiler team.
104+
* Library [API Change Proposal (ACP)](https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html) describes a change to the standard library.
105+
106+
## Frequently asked questions

0 commit comments

Comments
 (0)