> '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.
## 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!
* 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.")
This removes periods from the auto-generated project_slug (and also runs trim for good measure). Otherwise if you have a "." in your project name (e.g., you used a website domain name as your project name), you will encounter an error about it failing for a `project_slug.isidentifier()` check.
Update: changed "." to be replace with "_" instead of "", per request from @webyneter
sorl-thumbnail serialized and deserializes the storage class and during this
process location parameter is lost if factory is used. Using a full-fledge
storage class fixes this issue.
See: https://stackoverflow.com/a/18046120/104731
* Add note about using keep_local_envs_in_vcs
As a newbie, I wasn't sure about `keep_local_envs_in_vcs`, so I said yes, and when CC was building, it gave me the message:
"[INFO]: .env(s) are only utilized when Docker Compose and/or Heroku support is enabled so keeping them does not make sense given your current setup."
Seems like it could go in this documentation, and make things easier for newbies.
* Add me to CONTRIBUTORS.RST
* Add all internal IPs for multiple docker networks
When developing with modified docker-compose.yml that contains multiple
network definitions, all networks gateways of the created container
should be added to INTERNAL_IPS, otherwise Django-Debug-Toolbar will not
work.
* Add @flyudvik to contributors
* 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
Allow for dynamic bootstrap compilation
Exclude sublime artifacts
Make custom bootstrap vars file
Add custom bootstrap compilation
Add cookiecutter option
Use the right name for the file
Add explanation to generated README
Add self to contributors
Remove sublime exclusion
* Remove webpack and merge
* Put postgresql_version line back in cookiecutter.json
* Put goldhand back in contributors file, added ssteinerX
* Add *.egginfo to .gitignore
* Fix dangling endif in README.rst
* Add webpack as an option
Adds webpack as a js_taskrunner option to cookiecutter-json. Will clone @hzdg/cookiecutter-webpack --pydanny-django branch into the project using cookiecutter's api in post_hooks.
The static webpack project will be placed into the <project_slug>/static/<project_slug>/ directory.
The webpack configs are placed in the ./config/ directory.
The cookiecutter-webpack project includes react / redux / karma configurations that are brought into the project.
* Add webpack documentation
