COMPOSE_PROJECT_NAME should not be required for development setup

[benjaoming]

Details

If we setup a fresh environment, following Development Install, these steps will not work because COMPOSE_PROJECT_NAME isn't specified. Adding COMPOSE_PROJECT_NAME=community fixes the issue.

Expected Result

We can run inv docker.build and inv.docker.up without setting COMPOSE_PROJECT_NAME.

Actual Result

This is necessary:

COMPOSE_PROJECT_NAME=community inv docker.build
COMPOSE_PROJECT_NAME=community inv docker.up

Tested platform

Latest main, Ubuntu 22.04 with Docker 20.10.4

[humitos]

This environment variable is read from .env file that's on the repository automatically.

However, if you are using a different version of docker compose than the one from the requirements, this does not happen.

Can you confirm that you have the exact same version of docker compose than the one expected?

(from the phone)

[benjaoming]

I'm not sure why it doesn't work for me and works for others. I am running the commands from the same directory as the .env file is located in. According to documentation, this seems to have been a feature since 1.28, so then it should be because I am using a Docker Compose that's too new. But I think we are on the same Tested: all are using 1.29.x. See: https://docs.docker.com/compose/environment-variables/

Another thing that I wonder about: Aren't .env files supposed to be about setting the environment for the containers, and COMPOSE_PROJECT_NAME is actually a variable meant for the host system?

[benjaoming]

What happens during inv docker.up is this:

ERROR: pull access denied for community_server, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

...

I did cross-check with my setup and it seems that I ran inv docker.build which succeeded correctly without building community_server

Additionally:

it's not reading it for some reason and using dockerfiles_ to prefix the docker image

So this is actually normal Docker behavior since the docker-compose configuration is stored in a directory called "dockerfiles". From Docker docs

If you do not set this, the COMPOSE_PROJECT_NAME defaults to the basename of the project directory.

[humitos]

ERROR: pull access denied for community_server, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

This error makes more sense to me. This means that it's reading the COMPOSE_PROJECT_NAME correctly now. However, it seems that you haven't run inv docker.build with the COMPOSE_PROJECT_NAME properly set. So, you probably have an image named dockerfiles_server and not communit_server locally. Then it tries to find it out on Docker Hub, but it does not exist there and fails.

So this is actually normal Docker behavior since the docker-compose configuration is stored in a directory called "dockerfiles". From Docker docs

We want to avoid the default naming because we have images for community_ and commercial_ in the same system, and we need to differentiate them.

[benjaoming]

@humitos I have had this working since Wednesday - I wanted to add the above for clarity of the issue :)

Since docker-compose is invoked from a base directory called dockerfiles, that's why I have ended up with server and image names prefixed dockerfiles_.

I understand that everyone wants the Development Install to work without specifying COMPOSE_PROJECT_NAME and having it default to community in one way or another.

[benjaoming]

Another thing that I wonder about: Aren't .env files supposed to be about setting the environment for the containers, and COMPOSE_PROJECT_NAME is actually a variable meant for the host system?

I would like to propose that COMPOSE_PROJECT_NAME is a host system environment and does not belong in .env? See: https://docs.docker.com/compose/environment-variables/ + https://docs.docker.com/compose/reference/envvars/#compose_project_name

[benjaoming]

This is now fixed in readthedocs/common#148 🎉