{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigkyfc5wj7npuunfpnpfdbn7sonzjfkupw2g7cvqra7rfs3otqxii",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mg724yjqm5x2"
  },
  "path": "/t/alternative-to-cargo-new-templates-examples-as-build-target-templates/24047#post_3",
  "publishedAt": "2026-03-03T20:19:04.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Some random bits of intuition as to what commands might be available and do:\n\n  * `cargo new` without `--bin`/`--lib`/etc in an existing workspace would maintain the same behavior.\n    * The intuited behavior in this post probably conflicts in multiple ways with intuitive behavior for creating new workspace crates and/or current behavior. The purpose of this exercise was to only consider what I might intuitively expect when working on a single package, although I chose wording that acknowledges the difference between workspace and package.\n  * `cargo new --bin` in an existing workspace would add an implicit `main.rs` binary target to the closest package, erroring if it already exists.\n  * `cargo new --lib` in an existing workspace would add an implicit `lib.rs` library target to the closest package, erroring if it already exists.\n  * `cargo new --mod {path}` would create a new module at `{path}.rs` and add the `mod` statement to the parent module file.\n    * This is the existing `{path}` argument, and is mandatory.\n    * Error if the parent module is not present as a file.\n    * If not within `{srcdir}` and interactive, ask if the user wants to create the module `{srcdir}/{path}.rs` instead, otherwise error.\n  * `cargo new --example {path}` would create a new example file at `{path}.rs`.\n    * This is the existing `{path}` argument, and is mandatory.\n    * If you want a submodule in the examples directory instead, you must use `--example --mod`.\n    * Error if not an auto-discovered example location, unless `--name` is provided, in which case add an entry to `[[examples]]`.\n  * `cargo new --build` would add a `build.rs` to the closest package.\n    * No `{path}` necessary.\n    * Don't support `--build --mod`, that's a bit _too_ niche of a use case.\n  * `cargo new --script {path}` would initialize a file with the appropriate header for cargo-script.\n  * `cargo new --from {crate}` would initialize the created source file with the default template from `{crate}`.\n    * `{crate}` must be either:\n      * a direct dependency of the closest package, using renamed names;\n      * a dependency named in the workspace dependencies table, using renamed names; or\n      * a package in the lockfile with only a single version present.\n    * `{crate}@{version}` can also be used, in which case that package with that version constraint is used from the default registry.\n  * `cargo new --from {crate}/{example}` would use the specified example instead of the default example template.\n\n\n\nAlso, all examples are currently required to be binary crates, iirc. Using an example as a library or module template could choose to leave the unused `fn main` or strip it.\n\n* * *\n\nAn extra note I don't think you mentioned — dependencies used by the template/example that may not be dependencies of the local package target already. This is an added motivator for `[[example-dependencies]]` and perhaps even a dependencies table for specific examples.\n\nI have a crate that would greatly enjoy this, although it would require example dependencies and likely also the ability for this to include auxiliary support files. It would be entirely straightforward to include this information manually in the manifest; I don't expect it to be inferred.",
  "title": "Alternative to `cargo new` templates: examples as build-target templates"
}