In order to make wasa2il easy to use for developers I would like to improve the setup process.
Main objective: Have a single Settings file, and override it with ENV vars.
ENV vars are provided via a gitignored file called .env (Best practices)
Steps needed:
[x] Stop recommending the initial_setup.py because it creates another local_settings.py file
The script does a lot like creating a secret key, configuring sqlite, migrate, create superuser, populate with fake data etc.
This should simply be documented and the dev can decide if he needs to populate fake data etc
When a user has run also the initial_setup script, the Docker container stops using the mysql container and starts writing to an sqlite db inside the app container. Which is not the 'docker way'
[X] Instead recommend virtualenv as the way do develop
[x] Remove the wasa2il/default_settings.py
[x] Don't import default_settings from wasa2il/settings.py lines 12-16
[x] In settings.py can we use TIME_ZONE = os.environ.get('APP_TIMEZONE') or 'Iceland' to override variables?
This will result in less confusion like 'which setting file am I now using'?
We use a single settings file, and overwrite it with ENV vars!
ENV vars should be read by the host via f.x. an .env file which must be gitignored!
In order to make wasa2il easy to use for developers I would like to improve the setup process.
Main objective: Have a single Settings file, and override it with ENV vars. ENV vars are provided via a gitignored file called
.env
(Best practices)Steps needed:
[x] Stop recommending the
initial_setup.py
because it creates anotherlocal_settings.py
fileinitial_setup
script, the Docker container stops using themysql
container and starts writing to an sqlite db inside the app container. Which is not the 'docker way'[X] Instead recommend
virtualenv
as the way do develop[x] Remove the
wasa2il/default_settings.py
[x] Don't import
default_settings
fromwasa2il/settings.py
lines 12-16[x] In settings.py can we use
TIME_ZONE = os.environ.get('APP_TIMEZONE') or 'Iceland'
to override variables?This will result in less confusion like 'which setting file am I now using'?
We use a single settings file, and overwrite it with ENV vars!
ENV vars should be read by the host via f.x. an
.env
file which must be gitignored!Django has a package which reads
.env
files for you: https://github.com/joke2k/django-environdocker-compose can read
.env
files without extra packages through theenv_file: .env
in docker-compose.yml