django_q 1.0 fails in ./manage.py check on python 3.4 django 2.0.8

[mattaw]

Installed via pip into a virtual environment. Version 0.9.2 runs fine. Version 1.0.0 breaks Django's manage.py badly enough that you can't get to makemigrations or migrate or any commands. Full error below.

Python is 3.4 (Redhat, sadly)
Django 2.0.8

Let me know if you need anymore information. Removing from installed apps problem goes away, adding django-q back and it fails.

> ./manage.py check
Traceback (most recent call last):
  File "./manage.py", line 15, in <module>
    execute_from_command_line(sys.argv)
  File "/opt/python/env/www.purdue.edu/bidc/os1/lib64/python3.4/site-packages/django/core/management/__init__.py", line 371, in exec
ute_from_command_line
    utility.execute()
  File "/opt/python/env/www.purdue.edu/bidc/os1/lib64/python3.4/site-packages/django/core/management/__init__.py", line 347, in exec
ute
    django.setup()
  File "/opt/python/env/www.purdue.edu/bidc/os1/lib64/python3.4/site-packages/django/__init__.py", line 24, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "/opt/python/env/www.purdue.edu/bidc/os1/lib64/python3.4/site-packages/django/apps/registry.py", line 120, in populate
    app_config.ready()
  File "/opt/python/env/www.purdue.edu/bidc/os1/lib64/python3.4/site-packages/django/contrib/admin/apps.py", line 23, in ready
    self.module.autodiscover()
  File "/opt/python/env/www.purdue.edu/bidc/os1/lib64/python3.4/site-packages/django/contrib/admin/__init__.py", line 26, in autodis
cover
    autodiscover_modules('admin', register_to=site)
  File "/opt/python/env/www.purdue.edu/bidc/os1/lib64/python3.4/site-packages/django/utils/module_loading.py", line 47, in autodisco
ver_modules
    import_module('%s.%s' % (app_config.name, module_to_search))
  File "/usr/lib64/python3.4/importlib/__init__.py", line 109, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 2254, in _gcd_import
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2226, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1129, in _exec
  File "<frozen importlib._bootstrap>", line 1471, in exec_module
  File "<frozen importlib._bootstrap>", line 321, in _call_with_frames_removed
  File "/opt/python/env/www.purdue.edu/bidc/os1/lib64/python3.4/site-packages/django_q/admin.py", line 7, in <module>
    from django_q.tasks import async_task
  File "/opt/python/env/www.purdue.edu/bidc/os1/lib64/python3.4/site-packages/django_q/tasks.py", line 12, in <module>
    from django_q.cluster import worker, monitor
  File "/opt/python/env/www.purdue.edu/bidc/os1/lib64/python3.4/site-packages/django_q/cluster.py", line 24, in <module>
    from django_q import tasks
ImportError: cannot import name 'tasks'

[thinkwelltwd]

django_q 1.0 supports Python 3.6+

FWIW, the IUS repo has python3.6 packages available.

[mattaw]

That would be why, the current documentation lists Python 3.4 but it is for 0.9.2. Sorry for taking up your time.

[Also for the IUS python3.6, I know it is there, my sysadmin's know it is there, but I can't get them to update it. So python 3.4 for me!]

[Koed00]

I'm aware of the issues with Python 3.4 and I've been trying to find a solution, but because the way 3.4 deals with imports (that was fixed in 3.5) it would mostly likely require me to restructure the whole app the prevent this circular import.

Maybe it could work by moving import from top to bottom and I'll give it another try.
But if anyone in the community has dealt with this before, I would be very happy with a solution.
Even if it's only for the few months that 3.4 still has to live.

[mattaw]

Hum,

Can you change the import at the top of cluster.py:

Bad:
from django_q import tasks

Good:
import django_q.tasks

and then all tasks become django_q.tasks, there are a couple that have tasks.async_chain. Those go to django_q.tasks.async_chain.

There could be a better way of doing this, but seemed the most minimal change.

Ref:
https://gist.github.com/datagrok/40bf84d5870c41a77dc6