Introduce a single source of truth for project domain name

[webyneter]

As of now, project domain name is determined at the initial, scaffolding stage only, for it to then be hard-coded into numerous files, -- it might take quite some time to accurately update all the occurrences once required.

Since the domain name is used across multiple file types, --

• python files (including migrations),
• templates,
• shell scripts,

-- introducing an environment variable representing the domain name might be the single feasible solution, IMO. As for the variable name, it might be DOMAIN_NAME.

To ensure the variable is accessible project-wide, -- and, given the fact that .env file comprising other variables is for production use only, -- I suggest that we create a separate, say, common.env file with the variable definition, referencing it through env_file setting in both dev.yml and docker-compose.yml like that:

env_file:
- common.env
- .env

(Elaborating on that even further, my other suggestion would be to contain 'orphan' variables scattered all around dev.yml in a separate dev.env file which can be stored in VCS likewise the development-specific variables it defines are.)
Yet, only a single .env file must be available at production, so we'd need to concatenate common.env and .env in an automatic manner (incorporating this functionality in, say, ./compose/django/create-env.sh, called upon in django service's command in docker-compose.yml before ./compose/django/gunicorn.sh is called should suffice).

To handle that, special treatment would be required for various kinds of files:

• python files (migrations included):

import environ
env = environ.Env()
# reference the variable via env('DOMAIN_NAME')

• templates: pass DOMAIN_NAME through the corresponding view's context;
• shell scripts: so far, ./compose/nginx/start.sh is the only place the domain name is utilized, and happily it's the only place where the problem is solved already (there, the use of nginx service-provided MY_DOMAIN_NAME variable is made, but referencing common.env in the nginx service's env_file would be one further enhancement).

I'm in huge appreciation of any critics and suggestions to follow; that would also be a pleasure for me to provide a PR ones we reach consensus on the issue.

[browniebroke]

I think the situation has improved slightly with changes from #1801

We might be able to simplify this a bit further, but not by much: https://github.com/pydanny/cookiecutter-django/search?q=DOMAIN_NAME&unscoped_q=DOMAIN_NAME

What do you think @webyneter? Is it still an issue?

[browniebroke]

Here is where it's used at the moment:

1. Env file, which should be the source of truth:

   https://github.com/pydanny/cookiecutter-django/blob/275c13292c4d35a808fcb50ae57a05795395350a/%7B%7Bcookiecutter.project_slug%7D%7D/.envs/.production/.django#L7

2. In production settings, as default values. Actually uses the source of truth if set:

   https://github.com/pydanny/cookiecutter-django/blob/7d1e90bdf5343299c31388981b6af7cb0e631bbb/%7B%7Bcookiecutter.project_slug%7D%7D/config/settings/production.py#L21

   https://github.com/pydanny/cookiecutter-django/blob/7d1e90bdf5343299c31388981b6af7cb0e631bbb/%7B%7Bcookiecutter.project_slug%7D%7D/config/settings/production.py#L140-L142

3. Traefik config (doesn't support environment variables it seems), little we can do IMO:

   https://github.com/pydanny/cookiecutter-django/blob/b312d516a422b08c299b57cdd3515a235f82b03e/%7B%7Bcookiecutter.project_slug%7D%7D/compose/production/traefik/traefik.toml#L41

4. In one of our migrations:

   https://github.com/pydanny/cookiecutter-django/blob/eb0297aeb32491de14fa2ae8fe2b6e85191c4198/%7B%7Bcookiecutter.project_slug%7D%7D/%7B%7Bcookiecutter.project_slug%7D%7D/contrib/sites/migrations/0003_set_site_domain_and_name.py#L16

   This is the only one where we could improve things by using the value from the environment. Maybe we can use the setting to proxy the default value from the scaffoling?