Support cargo-generate

[armandas]

cargo-generate is a popular tool for generating projects from templates and significantly lowers the barrier to starting.
This PR makes changes to support cargo-generate, enabling users to start a project with a single line:

cargo generate --git https://github.com/emilk/eframe_template

The core changes are:

• Replacing hard-coded project name and author with appropriate template placeholders
• Deleting scripts for filling in the templates

However, the bulk of changes are in order to update the github actions. The flow is as follows:

1. First, a project is generated using cargo-generate
2. The generated project is uploaded as an artifact
3. Each subsequent action downloads the generated project, instead of checking out the repository

Tangential changes to the actions:

• actions-rs actions are no longer maintained, so their usage has been removed. For rust toolchain, I'm using dtolnay/rust-toolchain action. Cargo commands are now just written out, instead of relying on an action.
• trunk is installed using cargo binstall instead of using wget

[c-git]

I love the idea but wouldn't this make it incompatible with using the github template feature?

[armandas]

Yeah, I guess that would be the reason to keep the scripts around...

[c-git]

Yeah, I guess if they use the GitHub template they can just change it manually or use the script (which will need to be updated).

[c-git]

Given the problem I encountered with not being able to run one of my programs after upgrading to 0.30.0 it was nice to be able to just clone the template and try to see if it works and then say I tried it unmodified in the issue #177. If we set it up for cargo generate then we'd no longer be able to run it without using cargo generate and it would break CI in this repo.

Given all of this I no longer think this is a good idea.

[armandas]

I don't see how initializing the template would end up compromising the repo, so I don't agree with that point.

With regards the CI, this PR updates the workflows so the CI continues to work.

[c-git]

I don't see how initializing the template would end up compromising the repo, so I don't agree with that point.

I agree with you it doesn't compromise the repo. However, there is something to be said for simplicity. When things are not working it's nice to be able to take as few steps as possible to get to a known working state.

With regards the CI, this PR updates the workflows so the CI continues to work.

I didn't test it yet but in case you know. Would cargo generate be able to modify the CI in the generated repo to be able to make it work in the new repo? I don't know for others but I really appreciated having it already setup to test and deploying my app automatically for me. I'm a bit more familiar with github actions now and it's not as big a deal for me but when I didn't understand this was very helpful for me that it came working.

And to be clear, I am not against going with this PR. I'm just pointing out two trade offs I hadn't thought of previously:

• Not being able to do a straight clone anymore
• And if the CI in the generated repo would be setup

That is not meant to take away from the fact that I more often want it to support cargo generate to quickly create a new project. It's just something to consider.

[armandas]

Ahh, I see what you mean. Indeed, generated project CI would not work as is. I guess this needs more thought.

[Jesse-jude]

Strengths
1. Modular job separation
• Jobs like check, check_wasm, test, fmt, clippy, trunk, and build are separated, which improves clarity and CI/CD pipeline structure.
2. Cross-platform compatibility
• The matrix build approach for the build job allows targeting multiple OS/targets.
3. Use of cargo-binstall for installing tools
• Speeds up installation compared to compiling from source.
4. Static analysis included
• clippy and rustfmt are integrated for linting and formatting.
5. Artifact handling
• Uses actions/upload-artifact and actions/download-artifact for intermediate steps.

Issues & Recommendations

1. Duplicate Job Name & Key Conflicts
   • There are two check jobs defined:
   jobs: check: name: Check ... check: name: Check needs: generate

Fix:
Rename one of them (e.g., check_initial and check_generated) to avoid overwriting.