Exemplar as a template using cargo generate POC

Beman Project Development
1

PR #94 is a proof of concept that turns exemplar into a template that generates skeleton Beman projects using the cargo-generate tool.

See GitHub - camio/foobar: Example generated repository using exemplar as a template for an example skeleton called “foobar” generated from this template.

Use of this template requires a cargo-generate installation:

  1. Install Rust (a cargo-generate prerequisite)
  2. cargo install cargo-generate (detailed instructions here)

Once cargo-generate is installed, run

cargo generate gh:camio/example --branch cargo-generate

and follow the prompts to generate a template.

cargo-generate’s usage guide can be found here.

I got a bit nerd snipped into playing with this after a conversation with @tzlaine earlier today.

1 Like
2

Is this simply to show up the python version: Working on new_project_from_exemplar.py - #16 by tzlaine

or is it complementary?

3

Hey this seems really interesting, but I kinda don’t see where we are going to adopt/ host this.
Maybe a specific branch of exemplar? Will cargo generate work with a branch?

Also, is there any equivalent tooling in pip’s eco system? We already need pip to install pre-commit, I feel we should evaluate that before we pull another package manager into our tooling.

1 Like
4

@Sdowney’s cookie-cutter branch does much the same thing. This was just a low-effort experiment using a different technology.

I haven’t though through about where it would be hosted. cargo-generate does work with branches and/or tags.

I’m aware of cookie cutter (see this). My understanding, which could be wrong, is that cookie cutter is a text templating engine that you’d use as a library whereas cargo-generate is a top-level application that instantiates a repo template.

1 Like
5

What is particularly interesting about Zach’s approach is that it becomes straightforward to update as the exemplar is improved, whereas with cookie cutter, and presumably any template system, you need a tool like cruft to do updates, which inevitably fails with enough divergence.

Good project infrastructure seems to be independent of the project itself, but connected just enough that it is difficult to put elsewhere. At least that’s been what I’ve seen. It’s also something that C++ projects are notoriously bad at, since we have no common infrastructure and aversion to dependency. At least if it doesn’t come bundled with the IDE.

The cookie cutter I put together used Zach’s script where I said the name of the project was {{cookiecutter.project_name}} and then fixed up syntax errors and upcasing. I’m seriously considering borrowing the script for my own projects, though.

6

I wonder if a two-tool approach would work best: one for creating an initial project template, and another which acts like a “tidy” that flags nonconformance issues and sometimes suggests fixes.

One thing I’d love in a tidy script would be an error that’s flagged when a header file is included in the include subdirectory, but is not mentioned in a CMakeLists.txt.