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.
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,
cmeandcmt). 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.