helpers: Add a --jinja option to ynh_add_config

[alexAubin]

The problem

cf YunoHost-Apps/Experimental_helpers#111

Solution

add a --jinja option to ynh_add_config to render the template using jinja. All bash variables are exported in a subshell. The rendering is done using j2cli which is available in debian since bullseye

PR Status

Tested using new unit tests

How to test

Try rendering a template using ynh_add_config --template=foo --destination=bar --jinja

[Josue-T]

Pushed some improvements on doc side.

Tested on one of my apps it look good.

Thanks

[Salamandar]

Actually I got a request, here in pseudocode :

if filename.endswith(".j2"):
    jinja = True

That would help using jinja2 for nginx/systemd/etc without having to add --jinja arguments to all the relevant helpers.

[alexAubin]

That would help using jinja2 for nginx/systemd/etc without having to add --jinja arguments to all the relevant helpers.

Weeeeell yeah but on the other hand we should be careful and think about what we want exactly ... The current templating is okay-ish and I'm not sure there's a huge gain in moving to jinja for the vast majority of cases, and I'm not sure the syntax is gonna be "cleaner". For example for nginx conf, implementing the whole thing about {% if path != "/" %} and replacing __PATH__/ with either $path/ or just / depending of the install-on-root vs install-on-subpath etc is not going to be way more elegant or whatever.

Or to rephrase, I don't see the gain of reworking all the configs of every app. A lot of energy went into homogeneizing things, I don't feel like seeing a bunch of apps switching every conf to jinja2 just for the sake of it and ending up with heterogenous practices with no benefits

To me this PR is about specific app configurations which are too complex to be handled by the "simplified templating" mechanism

[Josue-T]

From my point of view I'm to migrate progressively everything to jinja for theses raison:

• Migrating to jinja for an app is quite easy. We can easily update a template with a regex like sed. So, yes the packager need to migrate but it's quite easier than to migrate a package to packaging v2 as most of change can be automated.
• jinja is a standard template system and is known by many people while the current system is completely custom.
• To me the magic thing of __PATH__ / which remove the ending / depending of if the app is installed in root is not ideal. Without reading the code we can't really understand what is happening and it not documented at my knowledge. To my point of view for this ideally we should improve this part by reworking the path management.
• In long temp (by example in packaging v3), we could have also have jinja into the manifest and so by this way this could bring some nice feature to have some calculated value by jinja as same as in ansible. So this could be a way to fix ynh_permission_* helper should not be depreciated package_linter#128. And this way we have standard system unified based on jinja which is great.

Note that this is only my personal point of view. I don't mind if we keep it as it is. I just share my point of view.

[Josue-T]

Hello,

Well, in any case I'm to merge this PR as it is. It still be already a good improvement. The discussion about this can be later, more on packaging v3 side.