Repository: cookiecutter/cookiecutter-django

Issue:
Docker Django 4.1 template reload behavior
Using Django 4.1 under Docker gives trouble in development with the changed default behavior of the template loading. Templates are cached until restart since the cached loader is added as default: https://docs.djangoproject.com/en/4.1/releases/4.1/#templates

My current workaround is adding the next snippet to local.py

```
TEMPLATES[0]["OPTIONS"]["loaders"] = [
    (
        "django.template.loaders.filesystem.Loader",
        [APPS_DIR / "templates"],
    ),
    "django.template.loaders.app_directories.Loader",
]
```


Discussion:
Issue is with runserver_plus: https://github.com/django-extensions/django-extensions/issues/1766 `runserver` does not have this issue.
In my opinion is this the last blocking issue for updating to Django 4.1. There is a [fix](https://github.com/django-extensions/django-extensions/pull/1775) already present but it awaits approval. 

We can decide to drop `runserver_plus` in favor of `runserver` but does not have my preferences since it requires more changes. 
Thanks for your efforts in researching and fixing these issues upstream.
It's been a while since `django-extensions` made a release and the fix for this is in master but still not on pypi. 

My proposal is to drop `django-extensions` and use `runserver` as alternative. `runserver_plus` is as far as I can see the only extension used by this project so it would be an easy one. Although `runserver_plus` with the werkzeug debug interface is a magnificent piece of software people should be encouraged to use the debugger instead. What do you think? Do you use other extensions or are we safe to go without `django-extensions`.
> It's been a while since `django-extensions` made a release and the fix for this is in master but still not on pypi.
> 
> My proposal is to drop `django-extensions` and use `runserver` as alternative. `runserver_plus` is as far as I can see the only extension used by this project so it would be an easy one. Although `runserver_plus` with the werkzeug debug interface is a magnificent piece of software people should be encouraged to use the debugger instead. What do you think? Do you use other extensions or are we safe to go without `django-extensions`.

`django-extensions` killer feature is dev experience with its `shell_plus` command after using it, its hard to go back to `./manage.py shell`. Also it adds other such good time-saving CLI utils as well of which `runserver_plus` is one.
> Using Django 4.1 under Docker gives trouble in development with the changed default behavior of the template loading. Templates are cached until restart since the cached loader is added as default: https://docs.djangoproject.com/en/4.1/releases/4.1/#templates
> 
> My current workaround is adding the next snippet to local.py
> 
> ```
> TEMPLATES[0]["OPTIONS"]["loaders"] = [
>     (
>         "django.template.loaders.filesystem.Loader",
>         [APPS_DIR / "templates"],
>     ),
>     "django.template.loaders.app_directories.Loader",
> ]
> ```

Updated my cookiecutter project to Django 4.1.7 (but still with django-extension v3.2.1) and can confirm the above works with 1 more setting override for APP_DIRS to False:
```
TEMPLATES[0]["APP_DIRS"] = False
```

If not set to False then you would get:  `django.core.exceptions.ImproperlyConfigured: app_dirs must not be set when loaders is defined.`
Its a pitty it takes such a long time for `django-extensions` to create a release. 
@foarsitter I'm in favor of dropping `django-extensions`, since 4.2 is just around the corner and I would rather have an up-to-date boilerplate for new projects than some nice dev features, that I hardly use.

If someone needs it, it's just one pip install away anyways. 

See the goal of this project:
> Only maintained 3rd party libraries are used.
@Brandl then we are on the same page. `django-extensions` [should migrate to jazzband ](https://github.com/django-extensions/django-extensions/issues/933). 

We have a view options at this moment:

1) wait for a release
2) `runserver_plus` is a single file so it is an option to include it in the repo for time being
3) use runserver and keep the dependency 
4) use runserver but drop `django-extensions`

Option 2 has my favor I think. 

Ok, thanks for your patience everyone. Here are my thoughts on each options:

1. Django 4.2 has been released, so I think we've waited for long enough.
2. I'm not really keen on this: this single file will turn into multiple copies among all generated templates, and there is not a good way to update them after generation other than manually fixing.
3. I like that option, simple fix, with little drawbacks and easy to switch back once fixed. Maybe leave the old `runserver_plus` command commented out with a note and link about the issue to prevent our users to wasted time by switching before it's fixed.
4. As stated before, the dependency offers other nice features beyond `runserver_plus`, so I'm not keen about dropping it (yet)

> See the goal of this project:
> 
> > Only maintained 3rd party libraries are used.

It had some activity in the past few months, so I wouldn't consider it unmaintained. IMO the problem with that package is that it's doing too many things, which makes it a big job to keep it running. If the maintainer steps down, good luck finding someone who can cover all the complex aspects of the project. Hopefully that can be resolved eventually, but it won't happen overnight.



Resolving patch:
diff --git a/hooks/post_gen_project.py b/hooks/post_gen_project.py
--- a/hooks/post_gen_project.py
+++ b/hooks/post_gen_project.py
@@ -182,7 +182,7 @@ def handle_js_runner(choice, use_docker, use_async):
             dev_django_cmd = (
                 "uvicorn config.asgi:application --reload"
                 if use_async
-                else "python manage.py runserver_plus"
+                else "python manage.py runserver"
             )
             scripts.update(
                 {


Test patch: