So I’ve been thinking about this more because I do feel @ClausKlein pain. Maybe we should remove ‘the realness’ from examplar and just replace it with cookie cutter itself? I mean that’s the real purpose here anyway. What it would mean is that CI couldn’t work without running cookiecutter on the repo to produce input source, but do we care? @ednolan thoughts?
I don’t like a cookiecutter-only exemplar because it means that ordinary users can’t clone exemplar and play around with it without first having to run cookiecutter on it.
My feeling on maintainer pain is that the overhead only applies to maintainers of the exemplar repo, whereas the benefits apply to all users of exemplar as a template, and the goal of exemplar is to make life easier for its users, not its maintainers. This is similar reasoning to how we decided on beman-submodule over ordinary git submodules.
1 Like
Sure, but I’m not sure that asking the users to run one script to ‘realize examplar into identidy’ is a big ask. I mean, that’s the process they’d need to follow in order to realize joes-cool-lib anyway. It also has the advantage that once you don’t need to excise the cookie-cutter tree out of your new cloned repo after running the tooling. This is probably a topic for the sync meeting.
If the features of exemplar will be frozen, then the cookiecutter would make sense.
But at the moment, test_installed_package, cxx_modules, import std, … and more are still not supported or integrated.
It’s a fair point. For some extended period all this won’t be done. import std could only live off on a branch or something right now since the cmake support is so experimental (likely fixed by year end). The other ones should go in – I mean the cookiecutter update won’t be horrible as long as all the experimentation is done elsewhere and just plopped down as a final product here. I think with all of those we’re talking about a few cmake files that will be changed – maybe an example or two. Or am I missing something?
1 Like
In principal I agree with Eddie here: user experience has the bigger impact on adoption and general impression of a system. If the maintenance overhead becomes too big, then we can revisit, but I’d like to see that play out before trading off user ergonomics.