`docker-compose.yml` linked for manual docker install contain ansible if-statements about lemmy-docs HOT 6 OPEN

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

from lemmy-docs.

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.

from lemmy-docs.

cc @codyro @ticoombs

from lemmy-docs.

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.

from lemmy-docs.

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.

from lemmy-docs.

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.

from lemmy-docs.