Python 3.8 and Django 2.2.3 Issues

[Ehigie Aito]

Creating a project with Python 3.8 and Django 2.2.3, the MIDDLEWARE variable in the (link: http://settings.py) settings.py file is changed to MIDDLEWARE_CLASSES which makes running this command: '(link: http://manage.py) manage.py runserver' fail. Can anyone kindly try to reproduce this error?

[Curtis Maloney]

First for everyone reading, it's important to note that Python 3.8 hasn't been released yet.

Secondly, a new project in current Django will not emit "MIDDLWARE_CLASSES" in a new settings file.

Could you explain how you determined something had "changed" the setting?

Could you also provide details on how manage.py fails?  Perhaps a traceback?

--

Curtis

On Mon, 15 Jul 2019, at 20:57, Ehigie Aito wrote:

Creating a project with Python 3.8 and Django 2.2.3, the MIDDLEWARE variable in the (link: http://settings.py) settings.py file is changed to MIDDLEWARE_CLASSES which makes running this command: '(link: http://manage.py) manage.py runserver' fail. Can anyone kindly try to reproduce this error?

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2b4a4bf0-1fec-43b6-8c8e-88569eb57e45%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Curtis Maloney]

On Mon, 15 Jul 2019, at 21:23, Curtis Maloney wrote:

First for everyone reading, it's important to note that Python 3.8 hasn't been released yet.

To elaborate on this point - it's _close_ to release, so it's valuable to see how Django behaves with it.

--

C

[Ehigie Aito]

Like I said, in older versions of Django, that variable used to be named MIDDLEWARE_CLASSES, if I create a Django project with Python 3.7 and Django 2.2.3, its MIDDLEWARE but Python 3.8 and Django 2.2.3 its named MIDDLEWARE_CLASSES which on running python manage.py runserver fails. Here is the traceback:

Exception in thread django-main-thread:
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/threading.py", line 923, in _bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.8/threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "/home/pystar/.local/share/virtualenvs/del-wUbba1cG/lib/python3.8/site-packages/django/utils/autoreload.py", line 54, in wrapper
    fn(*args, **kwargs)
  File "/home/pystar/.local/share/virtualenvs/del-wUbba1cG/lib/python3.8/site-packages/django/core/management/commands/runserver.py", line 117, in inner_run
    self.check(display_num_errors=True)
  File "/home/pystar/.local/share/virtualenvs/del-wUbba1cG/lib/python3.8/site-packages/django/core/management/base.py", line 436, in check
    raise SystemCheckError(msg)
django.core.management.base.SystemCheckError: SystemCheckError: System check identified some issues:

ERRORS:
?: (admin.E408) 'django.contrib.auth.middleware.AuthenticationMiddleware' must be in MIDDLEWARE in order to use the admin application.
?: (admin.E409) 'django.contrib.messages.middleware.MessageMiddleware' must be in MIDDLEWARE in order to use the admin application.
?: (admin.E410) 'django.contrib.sessions.middleware.SessionMiddleware' must be in MIDDLEWARE in order to use the admin application.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fc05ecd2-41a0-4326-9fe9-f3a80128c49f%40www.fastmail.com.

[James Bennett]

On Mon, Jul 15, 2019 at 4:36 AM Ehigie Aito <aitoe...@gmail.com> wrote:

Like I said, in older versions of Django, that variable used to be named MIDDLEWARE_CLASSES, if I create a Django project with Python 3.7 and Django 2.2.3, its MIDDLEWARE but Python 3.8 and Django 2.2.3 its named MIDDLEWARE_CLASSES which on running python manage.py runserver fails. Here is the traceback:

This seems very unlikely. Here is the default settings file Django 2.2.3 will create:

https://github.com/django/django/blob/2.2.3/django/conf/project_template/project_name/settings.py-tpl#L42

It contains MIDDLEWARE. It does not contain MIDDLEWARE_CLASSES.

Are you 100% completely certain that:

* You do not have an older version of Django that might have been used to generate the settings file, and

* You are not using any sort of custom project template that hasn't been updated to use the MIDDLEWARE setting?

[Ehigie Aito]

Not at all, I create all new Django projects from scratch and with pipenv. This only happens with Python 3.8.0 b1

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg-H8H%2B7gUTaxp1zMBnG_7%3DLfycDSGCHDsFVmSm0SuhRXg%40mail.gmail.com.

[Curtis Maloney]

On Mon, 15 Jul 2019, at 21:36, Ehigie Aito wrote:

Like I said, in older versions of Django, that variable used to be named MIDDLEWARE_CLASSES, if I create a Django project with Python 3.7 and Django 2.2.3, its MIDDLEWARE but Python 3.8 and Django 2.2.3 its named MIDDLEWARE_CLASSES which on running python manage.py runserver fails. Here is the traceback:

So you're saying that "django-admin startproject" will produce a different settings file based on the version of Python?

Can you show us a comparison, please?

Exception in thread django-main-thread:

Traceback (most recent call last):

  File "/usr/local/lib/python3.8/threading.py", line 923, in _bootstrap_inner

    self.run()

  File "/usr/local/lib/python3.8/threading.py", line 865, in run

    self._target(*self._args, **self._kwargs)

  File "/home/pystar/.local/share/virtualenvs/del-wUbba1cG/lib/python3.8/site-packages/django/utils/autoreload.py", line 54, in wrapper

    fn(*args, **kwargs)

  File "/home/pystar/.local/share/virtualenvs/del-wUbba1cG/lib/python3.8/site-packages/django/core/management/commands/runserver.py", line 117, in inner_run

    self.check(display_num_errors=True)

  File "/home/pystar/.local/share/virtualenvs/del-wUbba1cG/lib/python3.8/site-packages/django/core/management/base.py", line 436, in check

    raise SystemCheckError(msg)

django.core.management.base.SystemCheckError: SystemCheckError: System check identified some issues:

ERRORS:

?: (admin.E408) 'django.contrib.auth.middleware.AuthenticationMiddleware' must be in MIDDLEWARE in order to use the admin application.

?: (admin.E409) 'django.contrib.messages.middleware.MessageMiddleware' must be in MIDDLEWARE in order to use the admin application.

?: (admin.E410) 'django.contrib.sessions.middleware.SessionMiddleware' must be in MIDDLEWARE in order to use the admin application.

This does look troublesome. Can you show the settings file used?

--

C

[James Bennett]

On Mon, Jul 15, 2019 at 4:41 AM Ehigie Aito <aitoe...@gmail.com> wrote:

Not at all, I create all new Django projects from scratch and with pipenv. This only happens with Python 3.8.0 b1

Open a Python interpreter and type this:

import django

print(django.VERSION)

print(django.__file__)

Make sure VERSION returns (2, 2, 3, 'final', 0).

Then go to the location that printed for django.__FILE__ and examine the contents of conf/project_template/project_name/settings.py-tpl there.

[Ehigie Aito]

This is part of the settings file generated when I create a project with Python 3.7.3 and Django 2.2.3

MIDDLEWARE = [

    'django.middleware.security.SecurityMiddleware',

    'django.contrib.sessions.middleware.SessionMiddleware',

    'django.middleware.common.CommonMiddleware',

    'django.middleware.csrf.CsrfViewMiddleware',

    'django.contrib.auth.middleware.AuthenticationMiddleware',

    'django.contrib.messages.middleware.MessageMiddleware',

    'django.middleware.clickjacking.XFrameOptionsMiddleware',

]

[Ehigie Aito]

This is the contents of the file generated when I use Python 3.7.3 and Django 2.2.3

from django.utils.version import get_version

VERSION = (2, 2, 3, 'final', 0)

__version__ = get_version(VERSION)

def setup(set_prefix=True):

    """

    Configure the settings (this happens as a side effect of accessing the

    first setting), configure logging and populate the app registry.

    Set the thread-local urlresolvers script prefix if `set_prefix` is True.

    """

    from django.apps import apps

    from django.conf import settings

    from django.urls import set_script_prefix

    from django.utils.log import configure_logging

    configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)

    if set_prefix:

        set_script_prefix(

            '/' if settings.FORCE_SCRIPT_NAME is None else settings.FORCE_SCRIPT_NAME

        )

    apps.populate(settings.INSTALLED_APPS)

This is the output of the file generated when I create a project with Python 3.8.0 b1 and Django 2.2.3

from django.utils.version import get_version

VERSION = (2, 2, 3, 'final', 0)

__version__ = get_version(VERSION)

def setup(set_prefix=True):

    """

    Configure the settings (this happens as a side effect of accessing the

    first setting), configure logging and populate the app registry.

    Set the thread-local urlresolvers script prefix if `set_prefix` is True.

    """

    from django.apps import apps

    from django.conf import settings

    from django.urls import set_script_prefix

    from django.utils.log import configure_logging

    configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)

    if set_prefix:

        set_script_prefix(

            '/' if settings.FORCE_SCRIPT_NAME is None else settings.FORCE_SCRIPT_NAME

        )

    apps.populate(settings.INSTALLED_APPS)

Notice anything? Django 2.2.3 and Python 3.8.0 b1 fails

[Ehigie Aito]

I actually thought pipenv was the issue, and used virtualenv to create my django project with Python 3.8 and Django 2.2.3.
In the settings file, its still named as MIDDLEWARE_CLASSES instead of MIDDLEWARE and trying to run the project makes it fail

[Ehigie Aito]

I actually thought pipenv was the issue, and used virtualenv to create my django project with Python 3.8 and Django 2.2.3.
In the settings file, its still named as MIDDLEWARE_CLASSES instead of MIDDLEWARE and trying to run the project makes it fail

On Monday, July 15, 2019 at 12:53:51 PM UTC+1, Ehigie Aito wrote:

[Curtis Maloney]

I think you're making an assumption about the cause of the problem, without evidence.

Yes, there's an issue shown in that traceback related to middleware, but I've not seen yet why you've concluded it's creating a settings.py with MIDDLEWARE_CLASSES.

I think the problem is more likely some change in Python 3.8 is making the middleware not initialise, or the detection of what's in the MIDDLEWARE list is not working.

Can you elaborate on what evidence you have that the combination of Python 3.8 and Django 2.2.3 is generating a settings.py with MIDDLEWARE_CLASSES ?

--

C

[Ehigie Aito]

Like I said, I didn't say the problem was from Django. I said it's from Python 3.8 because creating a project with Python 3.7 doesn't produce this traceback.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5a40defe-8a9c-46cc-b2f1-5cf4fea652b8%40www.fastmail.com.

[Curtis Maloney]

On Mon, 15 Jul 2019, at 22:13, Ehigie Aito wrote:

Like I said, I didn't say the problem was from Django. I said it's from Python 3.8 because creating a project with Python 3.7 doesn't produce this traceback.

I think it's quite clear there is an incompatibility with Django and Python 3.8a1.

I just don't think it's your original conclusion of "Creating a project with Python 3.8 and Django 2.2.3, the MIDDLEWARE variable in the settings.py file is changed to MIDDLEWARE_CLASSES"

I'm trying to ask for what _evidence_ you have that this change has happened.

As I said earlier, I think there is a change in how Python 3.8 works that is causing those checks to fail.

--

C

On Mon, 15 Jul 2019, 13:07 Curtis Maloney, <cur...@tinbrain.net> wrote:

I think you're making an assumption about the cause of the problem, without evidence.

Yes, there's an issue shown in that traceback related to middleware, but I've not seen yet why you've concluded it's creating a settings.py with MIDDLEWARE_CLASSES.

I think the problem is more likely some change in Python 3.8 is making the middleware not initialise, or the detection of what's in the MIDDLEWARE list is not working.

Can you elaborate on what evidence you have that the combination of Python 3.8 and Django 2.2.3 is generating a settings.py with MIDDLEWARE_CLASSES ?

--

C

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5a40defe-8a9c-46cc-b2f1-5cf4fea652b8%40www.fastmail.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BB1BD4atpnwQWiJBEYzGpc5orLcxj8%3DiMU1Y-kc%3DomAfELBZA%40mail.gmail.com.

[Ehigie Aito]

Do we try to investigate or just wait till the final version of Python 3.8 gets released? My knowledge of the inner workings of Django isn't that deep enough to be able to pinpoint what exactly is causing this for me.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4f1ba28c-97e3-465d-bf5a-235fbcedf501%40www.fastmail.com.

[Mariusz Felisiak]

I've just created empty project with Python 3.8.0b1 and Django 2.2.3 everything works properly.

[Ehigie Aito]

Ok, before I start let me apologize.

It seems I am the proverbial boy who cried wolf as I have discovered where the source of the problem. 
I hope my explanation will help anyone who might make the mistake I was making. 
Lets start:

On my development machine, I had Django 1.9.5 installed globally and in Django 1.9.5, in the settings.py file, now MIDDLEWARE is called MIDDLEWARE_CLASSES. Somehow in new Django projects I was creating with Python 3.8 in a virtualenvironment, calling django-admin to create it, Python 3.8 wasnt using the django-admin command of the installed Django in the virtual environment but was using that of the globally installed version 1.9.5 which has MIDDLEWARE_CLASSES and on completion, trying to run the project with Python 3.8 caused it to fail. This never happens with Python 3.7 though as it always uses the django-admin of the virtual environment.

Hope my apology is accepted.

Thank you all very much for your help.

Kind regards

On Monday, July 15, 2019 at 1:25:24 PM UTC+1, Curtis Maloney wrote:

On Mon, 15 Jul 2019, at 22:13, Ehigie Aito wrote:

Like I said, I didn't say the problem was from Django. I said it's from Python 3.8 because creating a project with Python 3.7 doesn't produce this traceback.

I think it's quite clear there is an incompatibility with Django and Python 3.8a1.

I just don't think it's your original conclusion of "Creating a project with Python 3.8 and Django 2.2.3, the MIDDLEWARE variable in the settings.py file is changed to MIDDLEWARE_CLASSES"

I'm trying to ask for what _evidence_ you have that this change has happened.

As I said earlier, I think there is a change in how Python 3.8 works that is causing those checks to fail.

--

C

On Mon, 15 Jul 2019, 13:07 Curtis Maloney, <cur...@tinbrain.net> wrote:

I think you're making an assumption about the cause of the problem, without evidence.

Yes, there's an issue shown in that traceback related to middleware, but I've not seen yet why you've concluded it's creating a settings.py with MIDDLEWARE_CLASSES.

I think the problem is more likely some change in Python 3.8 is making the middleware not initialise, or the detection of what's in the MIDDLEWARE list is not working.

Can you elaborate on what evidence you have that the combination of Python 3.8 and Django 2.2.3 is generating a settings.py with MIDDLEWARE_CLASSES ?

--

C

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5a40defe-8a9c-46cc-b2f1-5cf4fea652b8%40www.fastmail.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.

[Curtis Maloney]

No need to apologise ... we're all human - we can (and do) all make mistakes.  More importantly - we all learned :)

I believe this is why James was trying to verify which Django (and where) you were really invoking.

Problems like this are why a lot of people recommend against installing any Python packages globally.  Leave system python for the system :)

--

Curtis

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1b216c6b-d40e-4756-9dc6-1dea38242091%40googlegroups.com.