Make scaffold files updatable and optional

[lundybernard]

Add _skip_if_exists for Makefile, myst.yml, and index.md so a consumer with an already-populated site can run copier update without merge conflicts on those files

Add include_news, include_makefile, and include_team_tools questions (default true), each gated through _exclude. Sites can opt out of scaffold they don't use; the answers persist in .copier-answers.yml, so exclusions survive future updates without CLI flags.

Assisted-by: claude-code:claude-opus-4-8

[drammock]

I guess my main question here is "how often are users likely to re-run copier after they've started tweaking their site?" I don't know the answer, but maybe @bsipocz or @stefanv does?

[drammock]

this won't work as-is. the project key also has other stuff under it now (a static_files list) and there's a second plugin now too. My feeling is there's little harm in always including team-grid.mjs since it won't do anything unless the user inserts a team-grid directive.

[lundybernard]

True, we could just narrow it down, so that the project section is static, and the - team-grid.mjs is the only line gated by if include_team_grid. I also don't see any real harm in including it by default, its just a little unused disk-space+compute vs the extra prompt in the initial setup.

[drammock]

I'd lean here toward just letting the user delete / modify whichever items they don't want in the nav

[lundybernard]

As I understand it, setting the include_ flags allows users to explicitly include/exclude the files/config opts. Without those, re-running copier to update their project will always add the unwanted files (manual delete each time) and overwrite their settings (resolve conflicts each time)... This won't eliminate those issues, but reduce their number.

The choices are explicit in .copier-answers.yml, and can be changed in the future, so adding a feature only requires removing it from .copier-answers.yml's exclude list and re-running copier.

The real question is still "do users only run copy once and maintain manually afterwards, or do they occasionally update the theme files?"

[drammock]

after actually reading the docs of copier (instead of blindly re-running the same command every time), I realize my objections are moot. copier is quite flexible in its subcommands and flags (copy vs recopy vs update, -A to re-use answers, etc). I still have a lingering "this is more complexity than we need" feeling, but I think I'm convinced that it's not a footgun and not worth spending any more time debating; the stakes are quite low.

[drammock]

these seem potentially useful for the end-user, although during theme development it is actually desirable to overwrite myst.yml possibly index.md and/or Makefile too.

[lundybernard]

Valid, there are ways to work around it, if you need to overwrite those files frequently.

My concern for users updating their theme is that we don't want to clobber these.

Tell me about your dev workflow where you need to overwrite these files frequently and we can find a good solution.

[drammock]

never mind. I was heavily editing footer.md.jinja and config/scientific-python.yml but not actually touching index.md.jinja or myst.yaml.jinja. and index.md.jinja is much simpler than the footer (it's just content, not really structure; the structure is inherited from book theme).

[stefanv]

I can see a case for bringing in the latest theme updates; we used to update the Hugo theme all the time (CSS tweaks etc.), and I imagine it will be the same here.

[lundybernard]

@stefanv I agree, and expect we will be updating these files frequently at least in the near future. Even long-term after the cadence of changes has slowed, I expect occasional updates to deal with changes in MystMD.

Copier is not really built for handling updates like this, so its always going to be a little awkward. Its worth considering if this is a temporary stop-gap to hold us over until we build a fully-fledged scientific-python MystMD theme, or if we really want to avoid that work and stick with project-level configuration instead.