* Bump Django version to 3.0.x to see what breaks
* Update places where Django 2.2 is mentioned to 3.0
* Update to latest Django 3.0 version
* Bump version in setup.py
https://docs.djangoproject.com/en/2.2/howto/error-reporting/#errors
> If those conditions are met, Django will email the users listed in the
> MANAGERS setting whenever your code raises a 404 and the request has a
> referer. It doesn’t bother to email for 404s that don’t have a referer –
> those are usually just people typing in broken URLs or broken Web bots.
> It also ignores 404s when the referer is equal to the requested URL,
> since this behavior is from broken Web bots too.
This allows for usage of settings variables in templates, e.g
```
{% if settings.USE_ANALYTICS %}
<!-- Google Tag Manager (noscript) -->
<noscript><iframe src="https://www.googletagmanager.com/ns.html?id={{ settings.GOOGLE_TAG_MANAGER_ID }}" style="display:none;visibility:hidden"></iframe></noscript>
<!-- End Google Tag Manager (noscript) -->
{% endif %}
```
> 'debug': a boolean that turns on/off template debug mode. If it is
> True, the fancy error page will display a detailed report for any
> exception raised during template rendering. This report contains the
> relevant snippet of the template with the appropriate line highlighted.
> It defaults to the value of the DEBUG setting.
https://docs.djangoproject.com/en/2.2/topics/templates/#module-django.template.backends.django
I could be wrong about this, but it seems like setting the template
DEBUG setting is redundant, since it should follow whatever the DEBUG
variable is set to.
The settings which are normally prefixed `CELERYD_` are for worker-related config, but since we instantiate the Celery app with a namespace, the prefix for these config should actually be `CELERY_`.
- Change celery app to not be a Django app, more like a WSGI app
- Define a Celery task in the Django users app
- Write a test to execute the task
- Update scripts to use the new app to start workers
- Update documentation
Fix#865
## Description
Fixes#591.
## Rationale
We are currently not testing many combinations, we run Flake8 on the generated project with default options, but that rarely catch any issues.
## Use case(s) / visualization(s)
Catch problems with invalid combinations, for instance, it fails due to Whitenoise breaking flake8 with `django-compressor` because `STATIC_URL` was undefined here:
b91c70d755/%7B%7Bcookiecutter.project_slug%7D%7D/config/settings/production.py (L185)
* Create a test matrix on Travis CI to help testing multiple options
* Change test_docker.sh to fail if any command in it fails
* Run black on the CI with --check option
* Fix formatting of project files using black
* Install black in the docker container
* Exclude migrations in black checks
* Fix Black formatting violations
* Run black on the whole generated project & fix issues
* Prettify and re-order settings entries
* Use old-style .format() for the time being
* Remove redundant linebreaks at the settings files' beginning
* Fix E303 too many blank lines
* Remove a redundant linebreak from requirements.txt
* Some linebreake juggling in config.settings.base
* More inline docs for DATABASES variable
Use of database url is not part of Django, but comes from django-environ. Was initially confusing where feature came from, as link points to offical django docs.
* Contributors update
* Introduce static asset build infrastructure
* Enhance gulpfile.js
* Introduce node service
* BrowserSync debug-only support
* Remove newline before BrowserSync debug-only support section
* FIx node Dockerfile package.json COPY
* Try fiixing node Dockerfile package.json COPY ones again
* Switch to `node:7-slim`
* Try switching to node:6
To account for possible node:7 docker-compose incompatibiltiy
* Revert "Try switching to node:6"
This reverts commit 62cc02df1a.
* Try switcging workdir to /app
* Try utilizing relative package.json path
* Resetting to the last version working locally with docker-compose 1.11.x
* Build upon the latest node:7.9-slim
* Stop dockerignoring package.json
* Fix typo
* Try a different package.json path
* Revert "Try a different package.json path"
This reverts commit f29f8500b8.
* Revert "Fix typo"
This reverts commit 02033729b5.
* Revert "Stop dockerignoring package.json"
This reverts commit 63c5491546.
* Upgrade docker-engine and docker-compose used by Travis CI
* Fix .travis.yml comments
* Inline docker-engine and docker-compose versions
* DEBUG: pwd
* Revert "DEBUG: pwd "
This reverts commit 6c2ed4321a.
* Try copying package.json to the same dir as node Dockerfile's
* Revert "Try copying package.json to the same dir as node Dockerfile's"
This reverts commit 24340a0783.
* Try out node:7.9
* Revert "Try out node:7.9"
This reverts commit 32286d33c2.
* Revert "Upgrade docker-engine and docker-compose used by Travis CI"
* Get rid of npm-check-updates
Reason: Reserved for the upcoming PR
* Get rid of npm-check
Reason: Reserved for the upcoming PR
* Get rid of 'standard' npm package
Reason: Reserved for the upcoming PR
* Clean up package.json
* Preserve package.json uncoditionally
Since we now have *unconditional* node.js integration, `package.json` must be out there whenever `node` service gets built
* Upgrade node service image to 7.10
* Document Node.js-Docker integration
* Fix gulpfile.js images region name
* Get rid of Gulp migrate task
* Document Gulp-Docker integration
* Introduce static asset build infrastructure
* Enhance gulpfile.js
* Introduce node service
* BrowserSync debug-only support
* Remove newline before BrowserSync debug-only support section
* FIx node Dockerfile package.json COPY
* Try fiixing node Dockerfile package.json COPY ones again
* Switch to `node:7-slim`
* Try switching to node:6
To account for possible node:7 docker-compose incompatibiltiy
* Revert "Try switching to node:6"
This reverts commit 62cc02df1a.
* Try switcging workdir to /app
* Try utilizing relative package.json path
* Resetting to the last version working locally with docker-compose 1.11.x
* Build upon the latest node:7.9-slim
* Stop dockerignoring package.json
* Revert "Stop dockerignoring package.json"
This reverts commit 63c5491546.
* Fix typo
* Revert "Fix typo"
This reverts commit 02033729b5.
* Try a different package.json path
* Revert "Try a different package.json path"
This reverts commit f29f8500b8.
* Upgrade docker-engine and docker-compose used by Travis CI
* Fix .travis.yml comments
* Inline docker-engine and docker-compose versions
* DEBUG: pwd
* Revert "DEBUG: pwd "
This reverts commit 6c2ed4321a.
* Try copying package.json to the same dir as node Dockerfile's
* Revert "Try copying package.json to the same dir as node Dockerfile's"
This reverts commit 24340a0783.
* Try out node:7.9
* Revert "Try out node:7.9"
This reverts commit 32286d33c2.
* Revert "Upgrade docker-engine and docker-compose used by Travis CI"
* Get rid of npm-check-updates
Reason: Reserved for the upcoming PR
* Get rid of npm-check
Reason: Reserved for the upcoming PR
* Get rid of 'standard' npm package
Reason: Reserved for the upcoming PR
* Clean up package.json
* Preserve package.json uncoditionally
Since we now have *unconditional* node.js integration, `package.json` must be out there whenever `node` service gets built
* Upgrade node service image to 7.10
* Document Node.js-Docker integration
* Fix gulpfile.js images region name
* Get rid of Gulp migrate task
* Document Gulp-Docker integration
* Remove Gulp-Docker integraton not supported initialization message
