* This way, scripts from external URLs are loaded asynchronously. By putting it at the top of the file, the browser parses it first, downloads it while continuing to parse the HTML, and then executes on parsing finish
* Additionally, developers will not need to use $(window).ready() or the like in their files anymore.
* Added inline_javascript tag in case anyone wants to use the bottom of the HTML page to execute some Javascript. Using defer here has no effect as inline scripts defer by default
Signed-off-by: Andrew-Chen-Wang <acwangpython@gmail.com>
-serve, watch + live reload for docs + code file changes
-update project makefile + make.bat
-separate _source and _build
-add packages and paths to use autodoc
-edit/add documentation with examples (both at django-cookiecutter and inside generated project)
-add formatted comments in User model for pickup by Sphinx apidoc
-serve docs from a separate docs container for docker build
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 %}
```
I am getting an error if I create a signal.py file under users model. Here is the stacktrace
Tracking file by folder pattern: migrations
Unhandled exception in thread started by <function check_errors.<locals>.wrapper at 0x000002663A074048>
Traceback (most recent call last):
File "C:\Apps\Anaconda3\envs\registration\lib\site-packages\django\utils\autoreload.py", line 225, in wrapper
fn(*args, **kwargs)
File "C:\Apps\Anaconda3\envs\registration\lib\site-packages\django\core\management\commands\runserver.py", line 109, in inner_run
autoreload.raise_last_exception()
File "C:\Apps\Anaconda3\envs\registration\lib\site-packages\django\utils\autoreload.py", line 248, in raise_last_exception
raise _exception[1]
File "C:\Apps\Anaconda3\envs\registration\lib\site-packages\django\core\management\__init__.py", line 337, in execute
autoreload.check_errors(django.setup)()
File "C:\Apps\Anaconda3\envs\registration\lib\site-packages\django\utils\autoreload.py", line 225, in wrapper
fn(*args, **kwargs)
File "C:\Apps\Anaconda3\envs\registration\lib\site-packages\django\__init__.py", line 24, in setup
apps.populate(settings.INSTALLED_APPS)
File "C:\Apps\Anaconda3\envs\registration\lib\site-packages\django\apps\registry.py", line 120, in populate
app_config.ready()
File "C:\Users\srao\projects\kbs\kbs\users\apps.py", line 11, in ready
import users.signals # noqa F401
File "C:\Users\srao\projects\kbs\kbs\users\signals.py", line 3, in <module>
from .models import User
File "C:\Users\srao\projects\kbs\kbs\users\models.py", line 8, in <module>
class User(AbstractUser):
File "C:\Apps\Anaconda3\envs\registration\lib\site-packages\django\db\models\base.py", line 95, in __new__
"INSTALLED_APPS." % (module, name)
RuntimeError: Model class users.models.User doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS.
Having the signal be imported from project_slug.users.signal fixes the issue.
- 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
Following up on @webyneter attempt in #1205, which is now getting outdated, I've tried to make Gulp task runner work with Docker. There is no documentation yet, but this seems to work locally with the custom bootstrap compilation...
- [x] Add a node image for local developement
- [x] Proxy the django image rather than localhost in Browser sync, pass header to keep hostname
- [x] Don't call the runserver command from Gulp, let docker-compose handle
- [x] Update package.json & gulpfile.js templates to reduce the number of unwanted empty lines
- [x] Use [multi-stage build](https://docs.docker.com/develop/develop-images/multistage-build/) in production to make sure the static assets are produced
- [x] Update documentation
- [x] Verify that the previous issue with static assets missing from production isn't there
## Rationale
Currently, the static build isn't working nicely with Docker, extra manual setup is required.
Fixes#1762
* 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
