rebar3 icon indicating copy to clipboard operation
rebar3 copied to clipboard

Template system does not handle string values correctly

Open eproxus opened this issue 3 years ago • 1 comments

Pre-Check

  • [x] If you are filing for a bug, please do a quick search in current issues first
  • [x] For bugs, mention if you are willing or interested in helping fix the issue

Environment

$ rebar3 report "new custom key=foo"
Rebar3 report
 version 3.18.0
 generated at 2022-02-07T14:14:39+00:00
=================
Please submit this along with your issue at https://github.com/erlang/rebar3/issues (and feel free to edit out private information, if any)
-----------------
Task: new
Entered as:
  new foobar
-----------------
Operating System: x86_64-apple-darwin21.1.0
ERTS: Erlang/OTP 23 [erts-11.2.2.8] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe]
Root Directory: /Users/user/.asdf/installs/erlang/23.3.4.9
Library directory: /Users/user/.asdf/installs/erlang/23.3.4.9/lib
-----------------
Loaded Applications:
bbmustache: 1.6.1
certifi: 2.8.0
cf: 0.3.1
common_test: 1.20.2.2
compiler: 7.6.9.1
crypto: 4.9.0.2
cth_readable: 1.5.1
dialyzer: 4.3.1.1
edoc: 0.12
erlware_commons: 1.5.0
eunit: 2.6
eunit_formatters: 0.5.0
getopt: 1.0.1
hipe: 4.0.1
inets: 7.3.2.2
kernel: 7.3.1.4
providers: 1.9.0
public_key: 1.10.0.1
relx: 4.6.0
sasl: 4.0.2
snmp: 5.8.0.1
ssl_verify_fun: 1.1.6
stdlib: 3.14.2.2
syntax_tools: 2.5
tools: 3.4.4

-----------------
Escript path: undefined
Providers:
  app_discovery as build build clean compile compile cover ct cut deploy deps dialyzer do edoc escriptize eunit get-deps help install install_deps list lock new organization owner path pkgs publish release relup report repos retire search shell state tar tree unlock update upgrade upgrade upgrade user version version xref
  • [x] Verify whether the version of rebar3 you're running is the latest release (see https://github.com/erlang/rebar3/releases)

Current behaviour

String values in templates are rendered as lists and not binaries. Generally, this is fine when everything is a string, but a template cannot have conditional sections depending on that key.

The following configuration and template:

{variables, [
    {key, false, "The key"}
]}.
{foo, [{{#key}}{{.}}{{/key}}]}.

Yields with the key key=foo:

{foo, [102111111]}.

This is not what most users would expect, I think.

bbmustache treats string values as a lists of items, thus each value in the key is printed separately, 102, 111 and 111.

This also makes it impossible to use template flags, e.g.:

{{#key}}
{foo, [static_thing]}.
{{/key}}

This currently renders:

{foo, [static_thing]}.
{foo, [static_thing]}.
{foo, [static_thing]}.

One item for each ASCII character in the string value.

Expected behaviour

I would expect the output to be:

{foo, [foo]}.

The solution is to convert all strings to binaries in the context before sending them to bbmustache:render().

eproxus avatar Feb 08 '22 12:02 eproxus

Explanation for the bbmustache behavior: https://github.com/soranoba/bbmustache/issues/67

eproxus avatar Feb 08 '22 12:02 eproxus