chevdor/tera-cli

A command line utility on top of the tera templating engine. Takes json|yaml|toml as input and can merge ENV in. You may see it as envsubst on steroid.

tera-cli's Issues

Issue with --env-only

Using --env and --env-only fails:

tera --env --env-only --template templates/release.md
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/wrapped_context.rs:122:59
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Current workaround:

echo {} | tera --env --template templates/release.md --stdin

Extension not supported: Some("yml")

Hi,

I am getting the following error when I pass the yml context data as a file and not stdin

tera -t rules\namingConvention.tera convention.yml
thread 'main' panicked at 'Extension not supported: Some("yml")', src\wrapped_context.rs:167:21
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Any ideas?

Thanks

line breaks are not respected

this is the current template MD and rendered output:

This is how it should render it:

The wrongly formatted MD will be ignored by the mdbook and thus never rendered into the HTML nor served.

I think the issue is with the CLI, but i am not 100% sure. Better to have it reported here than there since the polkadot_network_discovery is only using this cli.

I've also looked into the code and couldn't find an obvious fix. I did find out that the tera has the linebreakbr utility but i couldn't make it work.

YAML/JSON support

It seems tera cannot handle YAML like

audit-events:
  sso.auth.success:
    description: Authentification success

Result

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: Msg("Failed to render '__tera_one_off'"), source: Some(Error { kind: Msg("Forloop containers have to be an ident or a function call (tried to iterate on 'Math(MathExpr { lhs: Expr { val: Ident(\"audit\"), negated: false, filters: [] }, rhs: Expr { val: Ident(\"events\"), negated: false, filters: [] }, operator: Sub })')"), source: None }) }', src/main.rs:64:66

Remove - from audit-events and you will get

Thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: Msg("Failed to render '__tera_one_off'"), source: Some(Error { kind: Msg("Tried to iterate using key value on variable `auditevents`, but it is missing a key"), source: None }) }', src/main.rs:64:66

Can one iterate over YAML map?

Fix readme

Currently, we need to support 2 README files, moreover, github picks the asciidoc file by default, the one it cannot fully handle properly 🤦

This issue is blocked by github/markup#1095

Allow random extensions

We may want to pass a custom extension such as .foobar.
In that case, we could pass an extra flag to provide the format (such as --yaml) or be smart and guess.

Is it possible Manipulating data?

Hello,
how can I use functions ??

Provide more prebuilt binaries

For CI systems where this tool might be used, I find it sometimes quite convenient to be able to just download a prebuilt binary instead of building it myself. I'd suggest building for all kinds of architectures and operating systems. For example, see the binary matrix and GitHub Action for it.

Consider enabling Fluent language functions by default

From #20:

I would kindly request you reconsider whether [the Fluent feature] should be enabled by default. My opinion and reasoning go like this: the people who care about the compile time and binary size (which are admittedly both heftier with the expanded dependency chain) are the ones most likely to have the tooling at hand to run cargo build --no-default-features themselves and get exactly what they want. On the other hand the people who [get their apps] by some other means such as prebuilt binaries, or more notably via distro package managers, are the least likely to be able to easily spin up their own tooling to get the full feature set added in [and the least likely to care how long it took to build]. I'm the one packaging for Arch Linux (and will likely promote this to the [extra] repository soon) and will be adding the feature flag by default, but what about people that install via Homebrew or apt or whatever? Those people will not care about the build time at all since it doesn't affect them and are unlikely to care much about the binary size either. On the other hand they might care that their app doesn't have the full feature set.

I think having features off by default makes a lot more sense for Rust libraries where the downstream compile time might be a significant consideration and the users (i.e. projects that spec dependencies) can much more easily add the features they need. I don't think it makes much sense to have them off by default for CLI tooling that people are likely to get in binary form from channels that don't provide options.

Add Fluent language functions

I have a need for a CLI tool tool that not only implements data templating but also gives access to localizations through Fluent. There are several tools for the Handlebars ecosystem (at least JS and Rust ones that I'm aware of) that make this possible but I would prefer to use Tera if possible. There doesn't seem to be anything out there yet, but the fluent_templates crate already has support for use as a Tera function, so it shouldn't be hard to bring the existing library functionality to a CLI.

Is this project interested in adding this functionality (either as a default feature or behind a feature flag), or should I consider forking or creating an all new project for this?

c.f. guangie88/tera-cli#31

Include autotools setup to ease downstream packaging/installation

First of all, seeing the justfile here as a job runner for developer tooling made me happy!

I realize this is a somewhat unconventional ask in the Rust ecosystem, but I would like to propose including GNU AutoTools tooling in this project. If this project would be willing to accept it, I have all the necessary bits worked out already for other projects and could pretty easily contribute it here.

Pros:

• No existing usage such as using cargo install directly to get a binary would change.
• Packaging for downstream distros would be easier and more normalized. Building Rust binaries is pretty easy by themselves, but when a project comes with other support files it gets a lot harder and distros end up adhoc-ing their way through. Many distros end up without all the possible files.
• Clap can easily be updated to provide shell completions and a man page matching the CLI usage. Getting these generated and installed these to the right locations is not something plain Cargo handles well, but almost every distro out there has built in support for autotools builds that do this right out of the box.
• Notable for this project because of the conflicting project of the same name autotools has support for building and installing binaries under alternate names, either with a prefix, suffix, or name transformation. This tooling is standardized and distro packagers know how to use it, so for example if they have a tera binary from the other project they could easily configure this one to install as teracli (./configure --program-suffix=cli). This would be corrected for in not only the binary name but the completion files and man page as well.

Cons:

• AutoTools is a bit arcane and can be obtuse, especially if you don't have a gray beard and haven't been hacking on Unix for decades. This would be mitigated by the fact that I have done this before and can contribute the whole thing and, once setup, it doesn't require much.
• The release process will be a little different that your other projects. How to handle versions can be adapted to whatever workflow is desired, but once a release is cut the best end user experience will be with a released source tarball (made with make dist) rather than just a Git generated archive. This will need to be generated and attached to releases for the best experience (of course that can be automated too).

As an example you can check out my git-warp-time project with is tooled up this way. You can build the binary or install with cargo build and cargo install like any Rust project, but if you download a source release or clone the repo and use ./configure && make && make install you get all the goodies like shell completions and the man page taken care of.

.DS_Store getting in the way

If you are using --include-path and this path happen to contain some invalid templates such as a .DS_Store file, you get served the following error:

* Failed to read template '"/.../scripts/changelog/.DS_Store"'

Allow multiple context(s)

Awesome library!

I have my data spread over multiple files. But I can specify only one value for context. This is blocking me from using this cli.

Issue templates seem wrong

The issue templates link to something weird entirely. Maybe just delete the issue templates. This is a fairly small project and it should be rather manageable even without templates. :)