add jinja processing to yaml config files

[ytjohn]

With a straight yaml file format, we do end up with a disadvantage over the Vagrantfile's ruby format, the great if statement.

 if File.directory?(File.expand_path("../sisterproject"))
    config.vm.synced_folder "../sisterproject", "/sisterproject"
 end

Being able to setup a shared folder or run a provisioner based on conditions would quite beneficial.

One of the first things I thought of for LXDock is that it could replace using vagrant+virtualbox on our Jenkins servers. But for those developing on macOS, they could still use virtualbox to bring up the LXDock environment. With some proper conditionals, you could use the same LXDock file for both scenarios.

One method would be a client api to expose this to python, so you could write your config files in python (sort of like flask/django use settings.py. Another method is how saltstack does it, which is using jinja.

shares:
{% if lxdoc['file.directory_exists' ]('/vagrant/myshare') %}
  - source: /vagrant/myshare/
    dest: /myshare
{% else %}
  - source: /path/to/my/workspace/project/
    dest: /myshare
{% endif %}

[ytjohn]

Here are some examples. First off, Vagrantfile is a ruby construct and can do a lot of flexible things, such as looping over a list of vm. https://www.vagrantup.com/docs/vagrantfile/tips.html

Saltstack uses jinja to manage which yaml is presented. https://docs.saltstack.com/en/latest/topics/jinja/index.html#jinja-in-states

Ansible uses jinja for default variables and loops. https://blog.codecentric.de/en/2014/08/jinja2-better-ansible-playbooks-templates/

[grahamgreen]

👍

[ghost]

It looks like an interesting idea, but I wonder how many actual use cases there is for this. After all, a lxdock config file is much simpler than a saltstack config file.

For example, if this "optional share folder with fallback" example is the only actual example we can come up with, it's probably a better idea to implement this feature directly, without jinja (for example by allowing source to be a list of folders).

[robvdl]

I think this could be useful but we would have to break compatibility with the older lxdock.yaml file format.

There is some basic variable substitution in lxdock 0.4 in the form ${ENVVAR} and is currently used to load .env files by some users.

This might be something to consider for an 0.5 release because it would break backwards compatibility, but it might be OK if we can still support the users loading .env files using the jinja2 format.

[shuhaowu]

Personally don't like having a weird, non-standard jinja yml file. It looks to lead to a road of unmaintainable mess both inside lxdock and possibly in the dev file.

I think we maybe able to provide equivalent functionality via some sort of per-project python plugin functionality where the python plugin file is in the same directory as the project. This plugin could then override/extend the yml file or completely replace it.