Configuration beyond codemeta.json

[rsdoiel]

Integrate CL-web-component elements in page.tmpl, page.hbs

I'm adopting footer-global on my project documentation sites from CL-web-component. It'd be nice to update the page.tmpl, page.hbs generated files to reflect that but I am concerned about making CMTools too specific to DLD/Caltech Library. The easy way would be to introduce some configuration option. The problem is when I look at repositories I'm seeing lots of configuration files that ultimately need to be managed. That's a success problem.

The deno-tasks.json generation faces a similar problem, it needs to know the executable and source file names to generate the cross compile statements needed to automate releasing software using Deno from a Makefile (or PowerShell script).

An idea I've had is that configuration of CMTools is NOT a repository specific solution. CMTools could look to a configuration in the home directory that applies rules based on a repositories' group affiliation (e.g. caltechlbirary versus rsdoiel), specifics for a repos (e.g. CMTools has two executables, cme and cmt). This would be outside the repository to avoid cluttering things up.

If I can identify that I am working on a group project (e.g. using Git's remote paths), I could maintain an association with templates. These could then determine what results page.tmpl or page.hbs (or deno-tasks.json) produce. This would involve a more elaborate installation process the first time CMTools was run. I would need to confirm that a single approach would work across macOS and Windows.

More thought is needed before I start trying to plan a code solution.

[rsdoiel]

For the use case of page.tmpl being specific to Caltech Library versus generic I've gone with taking advantage of Git providing a group name in the remote URL. If the group name matches "caltechlibrary" then the Caltech Library page.tmpl or page.hbs is generated. Otherwise a simple default is used.

Still thinking through the binary and source file issues for generating Deno tasks for cross compiling. One idea would be to simply always prompt for the binary names. Another idea was to embed them in the deno.json via comments (After prompting). I don't know if the deno.json file supports comments. The rest of the information like OS, CPU are available in the CodeMeta object already.