I think this is an overcomplication of things.
This is a non production setup, so the easiest would be to just keep the example.env file there.
If we want to highlight that .env files should not be exposed in github etc, we should keep only the .env file in the docker-compose.yaml.
The Makefile will need to be updated too, to adapt to this change.

@gerrykou
Thanks for raising the github exposure point.
That clarifies that there are 2 separate questions.

1. Should env files be in coded in docker-compose.yml
2. Should env files be committed to git

Question 1
Both env files do not need to be there, in fact even the env_file key can be deleted too (I tested this) because .env is automatically searched for. (my suggestion in last paragraph of 1st message could be improved)

https://docs.docker.com/compose/how-tos/environment-variables/set-environment-variables/#use-the-env_file-attribute

A container's environment can also be set using .env files along with the env_file attribute.

This language implies that env_file is only needed if extra env files not called .env are used, otherwise, docker can automatically search .env placed at the root of the project directory next to the docker-compose.yml.

One argument for env_file section being there is for it to be self-documenting, like how EXPOSE doesn't actually bind ports (-p 8080:80 does the job) but documents what is exposed. However, I don't see any examples on docker docs listing .env under env_file section.

Thus, I would prefer the entire env_file section to be removed, and let docker automatically search .env. (PR #150 still has env_file section).
This teaches students that "automatic discovery" is a thing, which helps them debug issues with pytest automatically discovering test folders by observing locations of __init__.py in future.

Question 2
In real work .env would not be on github, and example.env would be on github but with values removed. It was good the README required students to create .env from example.env to express the concept that example.env is a template, and I now realize it's just easier for bootcamp scaling/self-service purposes to prepopulate the values of example.env already.

Further improvements possible but not applicable to bootcamp

This bootcamp has only 1 env file (excluding template).
If there are ever 2 env files (excluding template), then further specifications on optionality can be done: https://docs.docker.com/compose/how-tos/environment-variables/set-environment-variables/#additional-information-1

Would love to learn about how teachers can set things up correctly (demonstrating not just the end state, but real workflows) when teaching infrastructure topics, and similar problems faced.

Since this bootcamp aims to train engineers who can get jobs, and interviews would have rounds of code review, a student may fail in the operational details when asked to explain code, even if he gets all the concepts in the bootcamp, thus the emphasis on having a reason for every line of code.

1. Yeah agree, as you said, i would keep .env file in the docker compose file for self-documenting.
2. example.env file should be committed to git for documentation too, having dummy-placeholder or development values only.

So my suggestion on PR #150 is how i have done it and i would do it in my workflow.