I’ve created this Python script, new_project_from_exemplar.py, that just replaces the default README.md with a skeleton full of TODOs, and replaces the name ‘exemplar’ with your new project name throughout the exemplar project.
I did this because I’m making my first Beman lib, and I’m sure I’m going to make plenty of others down the line. I want to use the exemplar repo, but I don’t want to have to do all this manually every time.
The script also removes itself once it runs successfully, and makes a Git commit with an appropriate message. I’ll make a PR for this soon.
But I can’t yet! My changes don’t work in one way – they seem to break the linter checks, and I cannot figure out why.
@river could you take a look? I ask because git blame claims you are responsible for most of the linter workflow file, but maybe someone else can clue me in…?
My experiment can be found here . Thanks in advance!
I’m poking around and the GitHub template repo feature is extremely basic. It’s not all that different than forking the repository minus the GitHub fork tracking features.
We use cookiecutter at $dayjob quite a bit for our “new project” workflows. We could consider creating one of those from the exemplar, and then make exemplar a periodic instantiation of that cookiecutter template plugging in “exemplar” as the name.
I would expect someone could kick out a cookiecutter template project in an afternoon without a lot of effort. Mostly just clone the exemplar repo, restructure it a little, and find/replace exemplar with {{ cookiecutter.project_name }} or something like that.
Why I like cookiecutter:
It’s sort of the logical conclusion of what Zach is starting out with here.
It uses the Django/Flask templating engine for full templating features, if we want them: jinja2
Cookiecutter is in PyPI, so consume it however python dependency management works for you, including from the command-line
You can add arbitrary parameters to the template, starting with the project name, but it could include targeted C++ versions, etc.
There are pre and post generation hooks, which I expect would be interesting for validation purposes if nothing else. For instance, project names that do not fit what the Beman standard recommends or requires.
Yup. Did all of the above. As you mentioned later on, this just makes a fork, more or less. I’d like to immediately start making changes, pushing them, seeing CI green, etc. – thus the script.
A coockiecutter template would suit me as well, as long as it supports arbitrary changes that you could get with a general-purpose script. I never heard of it before right now.
I’m agnostic to the technology, but I think the capability is super useful. By that, I mean the ability to start from the latest-and-greatest version of the exemplar project, and start working on your new thing as soon as possible.
Back to the original question, @river, or anyone else who knows: ho do you disable the markdown linter? I simply do not coare, and it’s currently always read, possibly obscuring checks I do care about.
The only real problem is keeping the cookiecutter in sync with the canonical output. Once the change rate on the exemplar goes down a lot, it’s probably more feasible.
Yeah, but keeping all of the projects up to our standards is an existing problem. It doesn’t get harder just because there is a project template any more than it gets harder because there is an exemplar project.
This is partly why it’s important to follow through with our standards with automated tooling that can confirm standards are continually met as they evolve.
I used @tzlaine 's script to convert to a cookiecutter, making all the options things like “{{cookiecutter.description}}”, then fixed up things that cookiecutter complained about. That is: