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_`.
reverting back Werkzeug to version 0.14 based on discussion on #2070
I did the change locally on my windows laptop and can confirm that this is now working.
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
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)
## 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
## Description
Replace Caddy with Traefik
## Rationale
There is some trouble with the Caddy license (https://github.com/pydanny/cookiecutter-django/pull/1282#issuecomment-329617536)
@drdaeman suggested using Traefik (https://github.com/pydanny/cookiecutter-django/pull/1282#issuecomment-353655273) which supports ACME and also plays very nice with Docker.
## Comments
I am currently using the proposed setup on a live site and it working great so far. If this PR is of interest to the maintainers, then I could commit more changes and take care of the documentation. Of course, any suggestions by the more experienced people around here, are welcome!
* 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
## Description
This is the same as the pull request #1693 with the master branch merged into it to avoid all the extra unrelated commits which are already in master. Looks like Github is getting confused due to a rebase on that branch, which make that PR hard to review...
## Rationale
See #1693 - Locally, Redis is necessary only if Celery is used, while in Production it's also used for Caching.
## Use case(s) / visualization(s)
Fixes#1691
* Add failing test for travis.yml
I see three options to test travis.yml :
1. Testing that the YAML contains relevant value. Least useful and least
reliable, but simplest to implement.
2. Testing that the YAML is valid TravisCI YAML. Unfortunately this is
difficult / impossible. Doing 'travis lint' would succeed, this command
does not check for 'script' key presence and wouldn't be useful for us.
We could use 'travis-build' to verify that the YAML can be converted to
a worker config, but as of now 'travis-build' doesn't work out of the
box.
There is a new tool for validating travis YAML files 'travis-yml', but
as of now it's a ruby-only library and it's still a work in progress.
3. Running Travis CI task based on the generated YAML. This seems the
best approach, however since cookiecutter-django itself uses Travis CI,
that would require running Travis CI from within Travis CI.
Scheduling Travis CI job without a github push still requires a public
github repo, which is something that we can't generate on demand.
Given that I'm opting to use approach 1.
* Adds missing config to generated .travis.yml
The keys added are as follows:
1. 'script'
Required by Travis, cookiecutter-django used to provide it until it has
been removed together with hitch.
I'm assuming hitch has been replaced with pytest, I'm setting pytest as
the new value for the 'script' key.
2. 'install'
Not required by Travis, but necessary in our case; installs test
libraries, mostly pytest.
As of now this points to 'local.txt' requirements file. There used to be
a separate 'test.txt' requirements file but it has been decided to merge
it with 'local.txt', see discussion in
https://github.com/pydanny/cookiecutter-django/pull/1557 .
* Update CONTRIBUTORS.rst
[//]: # (Thank you for helping us out: your efforts mean great deal to the project and the community as a whole!)
[//]: # (Before you proceed:)
[//]: # (1. Make sure to add yourself to `CONTRIBUTORS.rst` through this PR provided you're contributing here for the first time)
[//]: # (2. Don't forget to update the `docs/` presuming others would benefit from a concise description of whatever that you're proposing)
## Description
[//]: # (What's it you're proposing?)
Added a note around CELERY_TASK_ALWAYS_EAGER = True in docker config for local development. This causes tasks to be executed on the 'main' thread rather than by the workers. I understand why that might be desirable, but thought it worth calling out incase (like me) it makes people think something is broken.
## Rationale
[//]: # (Why does the project need that?)
Ease of use/troubleshooting
## Use case(s) / visualization(s)
[//]: # ("Better to see something once than to hear about it a thousand times.")
