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.

[c-git]

Preamble

I've been thinking about this intermittently since this was first proposed and I need something like this. I personally feel like I need a simpler way to start a new egui project. I have a new application that I have to start for work and that brought this concern back to the forefront. My current proposed "solution" (the second one below) will require long term maintenance and I realized if I'm going to put in that work anyway I should propose it here and allow others to benefit from the maintenance I plan to do for it. I don't anticipate much more effort required than maintaining the scripts currently used. Very open to get other opinions on this to see if we can find an overall better solution.

Some possible solutions

1. Convert into cargo-generate repo: Go with the approach proposed here. Make this a cargo-generate template repo and update CI so that it will still work.
2. Make a cargo-generate branch: Keep the main branch of this repo the same and add a CI job to create a template in a separate branch. This allows us to be able to use cargo-generate without changing the main branch of this repo.
3. No change: No change keep using and maintaining the 2 fill_template scripts.
4. Use rust script: Use one fill_template written in rust. Instead of having platform dependent scripts to do the fill we just write only one in Rust.

Pros

1. Convert into cargo-generate repo
   • Allows users to use cargo-generate to create a new repo which is really quite a nice experience.
   • Only one set of places to update instead of needing two maintain two versions of the script.
2. Make a cargo-generate branch
   • All the same advantages as the first option
   • Allows users to continue to use the "Use this template" option Github provides.
   • CI in generated repos continues to work (we can delete ignore* the job that creates the template branch via a hook the ignore section in the config).
   • Easier for maintainers as local clones of the repo are still able to be run normally when doing updates and all the normal rust tooling would continue to work.
3. No change
   • Requires no action
4. Use rust script
   • Reduces the number of version of the script that need to be maintained

Cons

1. Convert into cargo-generate repo
   • Users would have a harder time using the "Use this template" option Github provides.
   • It will be tricky to get CI working properly in the generated repos as the CI for this repo will need to use cargo-generate and that won't work in the generated repos.
   • Normal rust tooling doesn't play nicely when you open the template repo in the IDE (from my limited experience).
   • Requires the install of cargo-generate by the user.
2. Make a cargo-generate branch
   • Requires a longer cargo-generate command to specify the branch.
   • If users use the "Use this template" option provided by github they will have an extra CI job creating a "useless" branch.
   • Requires the install of cargo-generate by the user.
3. No change
   • I feel this is the hardest to maintain long term as there are two scripts that need to be kept in sync but doesn't seem like they need to be updated often so this may not be a material concern.
   • Doesn't provide as "enjoyable" an experience as cargo generate
4. Use rust script
   • Not stabilized yet and requires the nightly compiler