Open naftulikay opened 5 years ago
Can you do something like "work_dir.push("**").push("*")
(not valid Rust but you get the idea) instead to get a glob?
If not, that looks like it could be a good idea but I would need to check up how the loaders in Jinja2 and others work to see if we can borrow ideas.
@Keats yeah I could definitely do that. I guess the main difference in what I'm seeking is to not have Tera load any templates when I instantiate a Tera
struct; rather I'd prefer a lazy-loading approach and just give Tera the directory from which to resolve relative template includes. The existing use-case makes a lot of sense for a typical web application, but not necessarily for CLIs.
jinjer was made as a tool to run on systems during cloud-init or during system package installation to render configuration files without needing a configuration management system like Puppet or Ansible installed on the local system. Thanks to Tera and Rust, I'm able to ship 4MiB static binaries which make templating system files easy and painless :)
I've recently written jinjer, a CLI tool for rendering Tera templates from stdin/files. It also discovers system facts and provides that to the Tera context as it executes.
I've had to use
Tera::one_off
for much of my work because of the nature of the usage of the CLI; I receive either aVec<PathBuf>
of template files to render or I render the template from standard input.Tera::one_off
makes sense for standard input, but there are limitations.What I'd really like to see would be a way to construct a
Tera
instance with the ability to pass a working directory so that relative templates are imported relative to this directory. The traditional glob string doesn't fit my use case, as I only need to render the templates passed on the command line.An API like
Tera::with_work_dir(work_dir: &PathBuf) -> Self
would be helpful so that the templates I'm rendering will resolve relative included templates properly.Interested to hear your thoughts.