`docker-compose.yml` linked for manual docker install contain ansible if-statements

[Sakrecoer]

This page list the docker-compose.yml for to download with wget. Since it contains a bunch of if statements to define the lemmy environment variables, docker compose up -d chokes on them.

$ docker compose up -d
parsing /opt/lemmy/docker-compose.yml: yaml: line 32: found character that cannot start any token

[Nutomic]

cc @codyro @ticoombs

[dessalines]

I see that... the problem is that docker-compose.yml now has those conditional template blocks. Not sure if there's a good way to resolve that without having separate docker-compose files, which I really don't want to do.

[codyro]

Here are a few quick thoughts on some options--none of which I'm in love with:

• The page already mentions removing Ansible-specific verbiage when downloading it directly--we could expand on that and mention you need to remove the Ansible/Jinja2-specific {% %} blocks as well.

• We can reconsider utilizing env files again, which should work around this as the Ansible-specific conditionals would be in those instead of the docker-compose.yml file.

• We can maintain multiple copies of the docker-compose.yml file, but as @dessalines noted, that's less than ideal.

• We can provide snippets to strip the Ansible-specific blocks using sed/awk/something.

[dessalines]

I'd vote for option 4 (same as option 1, but we give them the remove command), as long as there's nothing vital in those conditional blocks.

[Nutomic]

I still dont really see whats the advantage of using vars.yml over .env so I would simply switch to the latter.

[ticoombs]

whats the advantage of using vars.yml over .env

FWIW, there isn't really. Ansible (generally speaking) is yaml with jinja templating. As such the files are yaml based. .env does not really make sense unless the environment variables were for the apps inside (ie; if we created .env files for lemmy/lemmy-ui/etc). because it would still be yaml inside the .env file if we needed to import it for ansible.