Update bokeh.server.django to work with Django 3.2

[ejprinz]

bokeh==2.3.1
Django==3.2

Description of expected behavior and the observed behavior

bokeh.server.django works with Django 3.2

Complete, minimal, self-contained example code that reproduces the issue

In a Django 3.2 project, in <project_name>/settings.py:

INSTALLED_APPS = [
         'bokeh.server.django',
        ]

Then run

python manage.py shell

Stack traceback and/or browser JavaScript console output

Traceback (most recent call last):
File "manage.py", line 21, in
main()
File "manage.py", line 17, in main
execute_from_command_line(sys.argv)
File "/home/ejprinz/code/venv/lib/python3.8/site-packages/django/core/management/init.py", line 419, in execute_from_command_line
utility.execute()
File "/home/ejprinz/code/venv/lib/python3.8/site-packages/django/core/management/init.py", line 395, in execute
django.setup()
File "/home/ejprinz/code/venv/lib/python3.8/site-packages/django/init.py", line 24, in setup
apps.populate(settings.INSTALLED_APPS)
File "/home/ejprinz/code/venv/lib/python3.8/site-packages/django/apps/registry.py", line 91, in populate
app_config = AppConfig.create(entry)
File "/home/ejprinz/code/venv/lib/python3.8/site-packages/django/apps/config.py", line 255, in create
return app_config_class(app_name, app_module)
File "/home/ejprinz/code/venv/lib/python3.8/site-packages/django/apps/config.py", line 38, in init
raise ImproperlyConfigured(
django.core.exceptions.ImproperlyConfigured: The app label 'bokeh.server.django' is not a valid Python identifier.

The root cause is that Django 3.2 now checks that app labels are identifiers. This is done in the file
...site-packages/django/apps/config.py, line 37-40:

        if not self.label.isidentifier():
            raise ImproperlyConfigured(
                "The app label '%s' is not a valid Python identifier." % self.label
            )

So, "bokeh.server.django" is not a valid identifier. An easy fix for bokeh is to change one line in
site-packages/bokeh/server/django/apps.py

Replace line 41 by:

    name = 'bokeh.server.django'
    label = 'bokeh_server_django'

With this fix Django 3.2 works again with Bokeh, but in the users' code, the calls to:

apps.get_app_config('bokeh.server.django')

have to be replaced by:

apps.get_app_config('bokeh_server_django')

which is not a big deal but should be mentioned in the release notes.

[bryevdv]

cc @bokeh/dev There have been a large uptick in issues and questions around this in the last few weeks. If we cannot maintain this functionality in Bokeh, we should start preparing to sunset and remove it.

[philippjfr]

Certainly wouldn't object to moving it out of the bokeh repo. That said I also don't see an issue with saying "we support Django 2, if you need Django 3 support fund that work or contribute".

[bryevdv]

@philippjfr I would be fine with that if an explicit version check and error raise if the version is too new.

That said, AFAICT folks are having issues with Django 2 and newer Bokeh versions as well.

As an aside I would say that this django work is more like a prototype of a more general problem I would like to tackle: namely, making the Bokeh protocol usable over different transport layers. But I think that will have to be developed from the ground up, and if/when that is done, perhaps Django channels support will fall out as a special case.

[p-himik]

The Django 2 code is still something that needs to be supported, unless it's removed.
I would definitely try to avoid putting framework-specific stuff here, unless it's some rudimentary example.

making the Bokeh protocol usable over different transport layers

Oh, I remember our short discussion on the topic! :D

[bryevdv]

I would definitely try to avoid putting framework-specific stuff here, unless it's some rudimentary example.

Agree 100% and I think liberating the protocol would afford exactly that possibility. (It's just going to be a heavy lift and I have no idea when it might get done)

I'm just going to go ahead and put in my +1 to removing bokeh.server.django entirely. (I don't have any opinion about relocating to a separate repo, i'll leave that to others, in case we do proceed to remove it)

[bryevdv]

functionality moving to separate project