{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihfsj5fvzaogcij3jl5n565bvevkhjfynlozhhtfaijcmisgyustu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgeh44ciy5g2"
  },
  "path": "/t/alternative-to-cargo-new-templates-examples-as-build-target-templates/24047#post_12",
  "publishedAt": "2026-03-05T21:54:46.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "crates.io",
    "`tokio/hello_world`",
    "`tokio/custom-executor`"
  ],
  "textContent": "epage:\n\n> Associating: how does a package declare a relationship to its templates when those templates depend on it? This is one of the problems we are having with the \"recommended-bins\" idea for libraries to redirect people to their associated binary (e.g. a `cargo install foo` and tell people to instead run `cargo install foo-cli`)\n\nMight be my misunderstanding, but I don't think this is a problem? Since the template wouldn't be a crate published on crates.io, the hypothetical `templates` section wouldn't need to link to a published crate, so there's no chicken and egg publishing issue. While a template is a crate, it would just be file(s) as far as Cargo and crates.io are concerned, entirely contained within the `foo` crate.\n\nepage:\n\n> Being able to tell what to copy over. With an example this is easy. With a whole package, it gets more complicated.\n\nThat's part of the reason I feel like a proc-macro or `merge.rs` script might be a good starting point for \"additive\" templates. But for an initial implementation, I don't see why a template couldn't just be a straight copy-paste. `cargo new` already only makes sense for brand new projects, so there's no merging functionality required.\n\nepage:\n\n> MSRV: if this ends up requiring an MSRV bump, it will take even longer before people can use it\n\n`cargo` automatically picks up examples within an `examples/` folder, so I feel like picking up templates in a `templates/` folder would be fine? That would allow zero configuration within any `Cargo.toml`, so fully backwards compatible. The only issue I could forsee is if crates already have a `templates/` folder that isn't intended for this. In that case, I feel like you could treat invalid templates as a warning, then make it an error at some point in the future.\n\nepage:\n\n> Bootstrapping: packages have examples today. Maintainers would then need to write out templates and likely dual-source some examples as templates\n\nWhile templates and examples are related, I don't think they're the same thing. I see examples (currently) coming in two flavours:\n\n  1. How you _should_ use the crate. Such as `tokio/hello_world`\n  2. How you _could_ use the crate. Such as `tokio/custom-executor`\n\n\n\nIf there was an actual templates folder, type 1 examples could be moved to templates, while type 2 would remain as an example. Even without official `cargo` support, I think this would just be a good structural change for projects to adopt; when a user first wants to start using `bevy`, they'll open the examples folder and see a _huge_ list of examples, which is excellent! But it's hard for a new user to know which examples are type 1 and which are type 2.\n\nepage:\n\n> Nothing stops people from putting frontmatter in their examples today and in fact it might be useful to do so as people get confused reading an example and understanding how to replicate it. Even if we do example templates, we could merge the frontmatter in as well.\n\nThis does have a doubling up issue too though, since example dependencies must be declared in `dev-dependencies`, _and_ within the frontmatter (for the frontmatter to be useful). I see issues when those two lists de-synchronize.\n\nepage:\n\n> Build scripts as is are getting a lot of scrutiny for security a and build performance and we should be looking for ways to remove their need or consolidate down to fewer of them. [...]\n\nI do think a `merge.rs` is _less_ of a security concern than `build.rs` though, since it would be run exactly once when a user calls `cargo new`. I do agree it's a security concern though, and it'd be a hard sell if there wasn't some sandboxing. That's part of the reason I like the idea of a proc-macro instead of a build script, since it's _possible_ they could be built in such a way to prevent linking to host APIs and just be pure \"tokens in -> tokens out\" functions.",
  "title": "Alternative to `cargo new` templates: examples as build-target templates"
}