Alternative to `cargo new` templates: examples as build-target templates

epage:

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)

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

epage:

Being able to tell what to copy over. With an example this is easy. With a whole package, it gets more complicated.

That'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.

epage:

MSRV: if this ends up requiring an MSRV bump, it will take even longer before people can use it

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.

epage:

Bootstrapping: packages have examples today. Maintainers would then need to write out templates and likely dual-source some examples as templates

While templates and examples are related, I don't think they're the same thing. I see examples (currently) coming in two flavours:

1. How you should use the crate. Such as tokio/hello_world
2. How you could use the crate. Such as tokio/custom-executor

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

epage:

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.

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

epage:

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. [...]

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