The renderer should be set in the manifest

[yajo]

Right now, the only way to decide your app renderer is setting export DOCKERAPP_RENDERERS=some_renderer before running docker-app.

However, to do that, you need to know the renderer that the app writer had in mind when writing it.

If our intention is to have apps "just work", the renderer should be declared somewhere within the code, to avoid possible false positives when using the wrong renderer, or to avoid errors when user has a different environment variable set in place.

I think the manifest.yml file would be a good place for that. In case the renderer is chosen in the manifest, $DOCKERAPP_RENDERERS should be ignored IMHO.

[chris-crone]

Thanks for the feedback @Yajo.

We're still experimenting with renderers (and templating in general) which is why there are some rough edges. Our idea up to now has been that we will choose a single templating engine but this is interesting too.

[garethr]

Another alternative might simply be to use the extension. ie. docker-compose.mustache or docker-compose.jsonnet for example. This would remove the need for configuration in the common case?

[yajo]

Just to throw a new thought to the table: what would happen if you actually need to use the engine in manifest.yml itself? :thinking:

The file extension problem is syntax highlighting in most code editors, which should be fine always if the file extension is .yml, but would complicate things otherwise.

Maybe after all, the best would be to just use 1 engine, as @chris-crone said. Or otherwise forbid templating for the manifest part/file always.