Multiple data inputs?

[Victor B.]

I am using jinja2-cli for my resume and a part of my input data is:

[contact]
location = "where I live"
mail = "[e-mail]"
phone = "[phone]"
github = "victorbnl"

However now I would like to display not the keys of the elements but icons. So the solution would be to make a second file that matches the keys to icons:

location = "location-dot"
mail = "envelope"
phone = "phone"
github = "github"

Now there are two alternative solutions I've considered:

1. Using directly the icon names as keys, but I'd rather not have a envelope = "[e-mail]" in my data, that would be really odd.
2. Pre-processing the data to merge the two files before they get to jinja2-cli. That would add a little bit of complexity to the script, but feasible still.
3. Just including the icons in the first file with an [icons] section. Actually, that's not a bad solution, though I'd prefer to be able to separate code from data, for it is important to keep the data file as human-readable and editable as possible.

I think the most sensible way to implement it, with the current behaviour, would be to take any number of positional arguments as data sources, i.e.

jinja2-cli template.html data_file1.toml data_file2.toml data_file3.toml

[Matt Robenolt]

Would they potentially be different data formats? Like, one as toml, one is json, etc.

Just thinking out loud, why not just concat them together and pass to stdin?

Something like, cat data_file{1,2,3}.toml | jinja2-cli --format=toml template.html

So if they're different formats for each file, then I can see some value, but then that gets a bit tricky since we would need to rely on detection for each.

[Victor B.]

I think if no format is precised, that could be detected by the extension for each file, and if a format is precised, then it's the same for all the files. If a format is precised and one of the files is not in the given format, it's a user mistake so it would make sense to throw an error or just let the parser throw one.

Concatenating them is a very good solution though, I hadn't realised jinja2-cli could read input from stdin. Maybe it would be worth mentioning in the --help menu?

[Matt Robenolt]

I guess that's fair, it's only mentioned in the README in examples. :)

My original use case for this tool was for reading only from stdin and some tool would generate the output and pipe it into jinja2-cli.

Unless there's some reason not to, I'd probably suggest doing that, that way you can concatenate or join files however you want rather than expanding the API surface area to support it as variable length arguments.

[Victor B.]

Yes, I think this is a good compromise.