Re: Fellow Reports - July 2019

2019-07-15 Thread Mariusz Felisiak
Week ending July 14, 2019.

*Triaged:*
https://code.djangoproject.com/ticket/30623 - Remove duplicate call to 
`self.update` on RequestContext. (invalid)
https://code.djangoproject.com/ticket/30624 - Use numbered list 
reStructuredText syntax throughout the docs. (wontfix)
https://code.djangoproject.com/ticket/30622 - A better admin interface for 
non-relational databases like MongoDB. (wontfix)
https://code.djangoproject.com/ticket/30617 - test_check_constraints 
sometimes fails with no such table error. (worksforme)
https://code.djangoproject.com/ticket/30621 - CheckConstraint crash with 
__contains lookup on DateTimeRangeFields. (accepted)
https://code.djangoproject.com/ticket/30618 - AppConfig.name should be a 
full python path when using the optional directory. (accepted)
https://code.djangoproject.com/ticket/30614 - Add constraint name 
validation to system checks. (wontfix)
https://code.djangoproject.com/ticket/30626 - InlineModelAdmin fails of an 
empty form when DecimalField has default and blank=True. (invalid)
https://code.djangoproject.com/ticket/30628 - order_by() on union() 
querysets results with wrong ordering when the same field type is presented 
multiple times. (accepted)
https://code.djangoproject.com/ticket/30627 - In multi-table inheritance, 
querying with invalid pk raises different exception depending on the 
inheritance level. (fixed)
https://code.djangoproject.com/ticket/30629 - Add Redis to 
django.core.cache. (duplicate)
https://code.djangoproject.com/ticket/30630 - MemoryError raised by 
inspectdb executed on Oracle 12c. (invalid)
https://code.djangoproject.com/ticket/30631 - Prefixing Q Objects. (wontfix)
https://code.djangoproject.com/ticket/30633 - Group by 
concat(field1,field2) producing wrong result. (invalid)
https://code.djangoproject.com/ticket/30634 - "manage.py runserver" does 
not respect SCRIPT_NAME header. (wontfix)
https://code.djangoproject.com/ticket/13896 - Change language to dynamic 
attribute in syndication feed generator (duplicate)

*Reviewed/committed:*
https://github.com/django/django/pull/11544 - Fixed #30620 -- Made an 
example of admin-compliant custom user app pep8 compliant.
https://github.com/django/django/pull/11462 - Refs #29444 -- Added support 
for fetching a returned non-integer insert values on Oracle.
https://github.com/django/django/pull/11279 - Fixed #30397 -- Added 
app_label/class interpolation for names of indexes and constraints.
https://github.com/django/django/pull/11550 - Fixed #30628 -- Adjusted 
expression identity to differentiate bound fields.
https://github.com/django/django/pull/11551 - Fixed #30543 -- Fixed checks 
of ModelAdmin.list_display for fields accessible only via instance.
https://github.com/django/django/pull/11543 - Fixed #30619 -- Made 
runserver --nothreading use single threaded WSGIServer.
https://github.com/django/django/pull/11354 - Fixed #28289 -- Fixed crash 
of RawSQL annotations on inherited model fields.
https://github.com/django/django/pull/11556 - Doc'd --no-input option for 
createsuperuser.
https://github.com/django/django/pull/11555 - Fixed #30557 -- Fixed crash 
of ordering by ptr fields when Meta.ordering contains expressions.
https://github.com/django/django/pull/11560 - Fixed #30602 -- Made Extract 
raise ValueError when using unsupported lookups for DurationField.

*Authored:*
https://github.com/django/django/pull/11553 - Fixed #30621 -- Fixed crash 
of __contains lookup for Date/DateTimeRangeField when the right hand side 
is the same type.
https://github.com/django/django/pull/11559 - Refs #30557 -- Fixed crash of 
ordering by ptr fields when Meta.ordering contains F() expressions.
https://github.com/django/djangoproject.com/pull/924 - Updated to 
django-money==0.15.
https://github.com/django/django/pull/11562 - Simplified 
DateTimeRangeContains by making it subclass PostgresSimpleLookup.
https://github.com/django/django/pull/11563 - Simplified RangeContainedBy 
by making it subclass PostgresSimpleLookup.

Best regards,
Mariusz

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/0454eddc-57f5-4d10-bc1a-fdd67c977f1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Fellow Reports -- July 2019

2019-07-15 Thread Carlton Gibson
Hi all, 


Calendar Week 27 -- ending 07 July.


Triaged:

https://code.djangoproject.com/ticket/30607 -- How to use Django specific 
markup in the docstrings. (invalid)
https://code.djangoproject.com/ticket/30605 -- Define a variable TESTS in 
settings (wontfix)



Reviewed:

https://code.djangoproject.com/ticket/#30397 -- Allow app_label and class 
to be specified in the name argument for indexes and constraints.
https://github.com/django/django/pull/11481 -- Fixed #10403 -- Declaraive 
syntax for FormSet, ModelFormSet & InlineF…
https://code.djangoproject.com/ticket/6376 -- Allow using custom gettext 
domains
https://github.com/django/django/pull/11284 -- Fixed #28588 -- enable 
finding out about nonexistent permissions by s…



Authored:

https://github.com/django/django/pull/11530 -- Fixed #28588 -- Doc’d that 
has_perm() always returns True for active superuser.




Calendar Week 28 -- ending 14 July.


Triaged:

https://code.djangoproject.com/ticket/30607 -- How to use Django specific 
markup in the docstrings. (needsinfo)
https://code.djangoproject.com/ticket/30625 -- DatabaseCache backend raises 
TypeError if get/delete received key as integer. (Accepted)
https://code.djangoproject.com/ticket/30619 -- runserver fails to close 
connection if --nothreading specified. (Accepted)



Reviewed:

https://github.com/django/django/pull/10748 -- Fixed #23004 -- Cleanse 
sensitive request.META keys from DEBUG Views
https://code.djangoproject.com/ticket/23004 -- Cleanse entries from 
request.META in debug views
https://github.com/django/django/pull/11224 -- Fixed #23004 -- Hid 
sensitive environment parameters in debug view
https://code.djangoproject.com/ticket/29714 -- Make it easier to customise 
ExceptionReporter output.
https://code.djangoproject.com/ticket/30411 -- mprove traceback formatting 
in technical 500 text responses
https://code.djangoproject.com/ticket/30619 -- runserver fails to close 
connection if --nothreading specified.
https://code.djangoproject.com/ticket/30621 -- CheckConstraint crash with 
__contains lookup on DateTimeRangeFields.
https://github.com/django/django/pull/11482 -- Fixed #30573 -- Remove 
simple/easy/etc from documentation
https://github.com/django/django/pull/11548 -- Update Select2 to version 
4.0.7
https://github.com/django/django/pull/11546 -- Fixed #30624 -- Changed docs 
to use numbered list reStructuredText syntax.
https://github.com/django/django/pull/11543 -- Fixed #30619 -- runserver 
doesn't close connections when --nothreading is specified.



Kind Regards,

Carlton

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/cd58d2ff-1b97-496f-9f31-b4e9f0a66e77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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?

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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-developers+unsubscr...@googlegroups.com.
>  To post to this group, send email to django-developers@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.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/f5c649ee-7e01-488a-afcd-ab4faf5da1d5%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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.

On Mon, Jul 15, 2019 at 12:27 PM Curtis Maloney  wrote:

> 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
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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
> 
> .
> 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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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%2BB1BD4oKnqqFG4oLWmWO8At3L67EM%2B5TLA_RDrPNmK086V4UA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread James Bennett
On Mon, Jul 15, 2019 at 4:36 AM 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:
>

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?

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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

On Mon, Jul 15, 2019 at 12:39 PM James Bennett 
wrote:

> On Mon, Jul 15, 2019 at 4:36 AM 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:
>>
>
> 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?
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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
> 
> .
> 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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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%2BB1BD5ARUgq%3DjXJyrSgbKWUMKVAO7j1urOkU%2BBq3TU6ARnHFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/447ea06c-c3d9-43d3-848e-8ba27fd2d8ea%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread James Bennett
On Mon, Jul 15, 2019 at 4:41 AM Ehigie Aito  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.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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--q48U_5Ke9akjs5aqrCObkcZLtbQHmrgRRff8AqWhzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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',
]


On Monday, July 15, 2019 at 12:42:16 PM UTC+1, Curtis Maloney wrote:
>
> 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
>
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/002bb721-a76c-4052-8d0e-d59cf388ff2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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

On Monday, July 15, 2019 at 12:44:04 PM UTC+1, James Bennett wrote:
>
> On Mon, Jul 15, 2019 at 4:41 AM Ehigie Aito  > 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.
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/6a13d9ee-2258-4c0a-b775-8cab39995515%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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:
>
> 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
>
> On Monday, July 15, 2019 at 12:44:04 PM UTC+1, James Bennett wrote:
>>
>> On Mon, Jul 15, 2019 at 4:41 AM Ehigie Aito  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.
>>
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/9d8af1ae-c41e-4f11-996d-644543c54e03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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:
>
> 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
>
> On Monday, July 15, 2019 at 12:44:04 PM UTC+1, James Bennett wrote:
>>
>> On Mon, Jul 15, 2019 at 4:41 AM Ehigie Aito  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.
>>
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/ce354a4a-6870-4f1d-ba5a-93b21566fde9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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.

On Mon, 15 Jul 2019, 13:07 Curtis Maloney,  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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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,  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-developers+unsubscr...@googlegroups.com.
>>  To post to this group, send email to django-developers@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-developers+unsubscr...@googlegroups.com.
>  To post to this group, send email to django-developers@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
>  
> .
>  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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/4f1ba28c-97e3-465d-bf5a-235fbcedf501%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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.

On Mon, 15 Jul 2019, 13:25 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,  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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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
> 
> .
> 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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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/4f1ba28c-97e3-465d-bf5a-235fbcedf501%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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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%2BB1BD5Lg2eHG33MiywsiHECk7X-USSnf3pLnyiVn8d%2Bw4vhHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Error websocket 404

2019-07-15 Thread Adam Johnson
Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for the development of Django itself, not for support using Django.
This means the discussions of bugs and features in Django itself, rather
than in your code using it. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the django-users mailing list, or IRC #django on
Freenode, or a site like Stack Overflow. There are people out there willing
to help on those channels, but they might not respond if you don't ask your
question well. Stack Overflow's question guide can help you frame it well:
https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Thu, 11 Jul 2019 at 10:31, Aldian Fazrihady  wrote:

> Why there is http in this line:
> > proxy_pass http://unix:/.../daphne.sock;
>
> Which one do you want to use,  http or unix socket?
>
> On Thu, Jul 11, 2019 at 1:42 PM Fatemeh Ahmadzadeh <
> f.ahmadzadeh...@gmail.com> wrote:
>
>> Hi my  friends
>> I create daphne.sock for websocket and gunicorn.sock for http request ,
>> two ASGI and WSGI is activated
>>
>>
>> python manage.py runworker is excellent and dont have any Errors
>>
>>
>>
>>  nginx.conf proxy_pass equals to unixes. but have this errors according
>> to this
>>
>> server{
>>
>> listen 80;
>>
>> server_name 185.252.11.11 domain.com;
>>
>>
>>
>>
>>
>> location / {
>>
>> proxy_set_header Host $http_host;
>>
>> proxy_set_header X-Real-IP $remote_addr;
>>
>> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>>
>> proxy_set_header X-Forwarded-Proto $scheme;
>>
>> proxy_redirect off;
>>
>> proxy_pass http://../gunicorn.sock;
>>
>> }
>>
>> location /static/ {
>>
>> root
>> /home/Farzand-user/Farazan_Parvari_Project/Farzand_Parvar/Farazan_Parvari_Project;
>>
>> }
>>
>>
>>
>> location /ws/ {
>>
>>
>>
>> proxy_buffers 8 32k;
>>
>> proxy_buffer_size 64k;
>>
>> proxy_redirect off;
>>
>> proxy_http_version 1.1;
>>
>> proxy_set_header Upgrade $http_upgrade;
>>
>> proxy_set_header Connection "upgrade";
>>
>> proxy_read_timeout 86400;
>>
>> proxy_pass http://unix:/.../daphne.sock;
>>
>> proxy_set_header   Host $host;
>>
>> proxy_set_header   X-Real-IP $remote_addr;
>>
>> proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
>>
>> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>>
>> proxy_set_header X-Forwarded-Host $server_name;
>>
>>
>>
>>
>>
>>
>>
>> }
>>
>>
>> }
>>
>>
>> according to this page
>>
>>   https://avilpage.com/2018/05/deploying-scaling-django-channels.html
>>
>> http://masnun.rocks/2016/11/02/deploying-django-channels-using-daphne/
>> 
>> the HTTP request is wll but I have Errors in websocket  in console WebSocket
>> connection to 'ws://domain/ws/' failed: Error during WebSocket handshake:
>> Unexpected response code: 404
>>
>> server is centos with directadmin , nginx 1.15
>>
>>
>>
>> --
>> 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-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@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/5e29f063-5760-49ce-916c-303a6eec7a0f%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Regards,
>
> Aldian Fazrihady
> http://aldianfazrihady.com
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.goog

Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread Mariusz Felisiak
I've just created empty project with Python 3.8.0b1 and Django 2.2.3 
everything works properly.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/8063a6e7-dcbb-4dca-b814-27140ae1900d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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,  > 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 .
> 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
>  
> 
> .
> 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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread 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


On Tue, 16 Jul 2019, at 10:37, Ehigie Aito wrote:
> 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,  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.
>>> 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
>>>  
>>> .
>>> 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-developers+unsubscr...@googlegroups.com.
>  To post to this group, send email to djang

Re: Proposal: security enhancements

2019-07-15 Thread Jonathon Sumner
Hi all,

Sorry for jumping in on an old thread, but I stumbled across James' post 
after writing a similar wish list.  Securityheaders.com (and the Mozilla 
http-observatory) score an out-of-the-box Django site fairly harshly.  With 
that in mind, me and a colleague put together a very simple package 
(django-security-headers) to add some headers, package django-csp, 
self-test against a local http-observatory instance (using 
django-sslserver), and provide default settings to get a better score.

I completely agree with Jacob that adding CSP *post facto* can be a 
minefield, but I think it would promote better practices if Django shipped 
with secure defaults for CSP, referrer policy, etc. and required the user 
to turn these settings off for their application.

Anyway, although I would be a newbie contributor, I would be more than 
happy to pick up the thread started by James if the senior Django community 
sees value in it!  

Cheers,
Jonathon



On Tuesday, May 1, 2018 at 11:13:17 AM UTC-4, Jacob Kaplan-Moss wrote:
>
> Great ideas, James. I totally agree we shouldn't rest on our laurels, and 
> love the goal of pushing things forwards. Overall, I'm not sure a DEP is 
> needed: each of these things is fairly small and tightly scoped, can be 
> implemented on its own, and provides value independent of the whole. That 
> seems like a scenario where just a bunch of loosely-related PRs makes the 
> most sense. Added bonus: many of these things would be fairly easy pickings 
> for a new contributor. If you wanted, you could delegate/coordinate some of 
> this, and help us get more folks involved as a bonus.
>
> Some comments on specifics:
>
> On Tue, May 1, 2018 at 12:28 AM, James Bennett  > wrote:
>
>> Content Security Policy 
>>
>
> CSP is a tricky one. On the one hand, it's a tremendously effective 
> defense against XSS. But, it's pretty tricky to get right: I've seen 
> several sites struggle with a proper CSP config for years. It tends to be 
> beyond the grasp of your classic one- or two-person dev team. When you get 
> it wrong, it totally hoses your site. 
>
> Most complex sites find they need to operate in report-only mode for a 
> while and analyze the data before switching to enforce. And that requires a 
> good reporting/analysis mechanism (something like report-uri.com, or a 
> local equivalent). 
>
> So all that to say: I highly support exploring this more, but it could be 
> easy to turn CSP into a foot-gun. I don't think it's as easy as just 
> shipping django-csp and calling it a day; we'd need to make sure it's not 
> going to cause more problems than it solves.
>  
>
>> Referrer-Policy
>>
>
> +1, this seems like a no-brainer.
>  
>
>> Subresource integrity
>>
>  
> The jury seems to still be out on the value of SRI (at least, in my corner 
> of the security community). It has some serious problems with dynamic 
> assets, and with externally-hosted tools like Google Analytics. I'm not 
> convinced that the current spec is fully-baked enough for us to support.
>
> The admin's a special case since we tightly control what's shipped there; 
> SRI-for-the-admin would be a nice, if incremental improvement. Preventing 
> injection attacks in the admin is a very good thing :) 
>
> CORS
>>
>
>  Yup, another no-brainer.
>
> rel="noopener"
>>
>
> I'm not sure I get this one, might need to see what you come up with to 
> understand the effect.
>  
>
>> In my magical stretch-goal land, I'd also figure out a way to support
>>
> the pyup safety library[8] to scan for a requirements file and any
>> dependencies in setup.py, and warn if known-insecure versions are
>> specified.
>>
>
> This seems entirely doable! Of course, grappling with the various options 
> for dependency management might make this.. less fun (
> https://xkcd.com/1987/).
>  
> Jacob
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/a31b7f78-2e13-4190-aa58-9db2f00ac909%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal: security enhancements

2019-07-15 Thread Curtis Maloney
I think there is certainly a strong case based on "secure by default" to 
include this in core, where it would otherwise face the "it works fine as a 3rd 
party app" barrier to entry.

IMHO it would require, however, that the solutions be sufficiently generic as 
to not enforce an overly restrictive world view.

I, for one, would be very interested to see more details here on what changes 
you propose. Then, at least, we can keep a mailing-list history record of the 
discussion.

--
Curtis


On Tue, 16 Jul 2019, at 12:22, Jonathon Sumner wrote:
> Hi all,
> 
> Sorry for jumping in on an old thread, but I stumbled across James' post 
> after writing a similar wish list. Securityheaders.com (and the Mozilla 
> http-observatory) score an out-of-the-box Django site fairly harshly. With 
> that in mind, me and a colleague put together a very simple package 
> (django-security-headers) to add some headers, package django-csp, self-test 
> against a local http-observatory instance (using django-sslserver), and 
> provide default settings to get a better score.
> 
> I completely agree with Jacob that adding CSP *post facto* can be a 
> minefield, but I think it would promote better practices if Django shipped 
> with secure defaults for CSP, referrer policy, etc. and required the user to 
> turn these settings off for their application.
> 
> Anyway, although I would be a newbie contributor, I would be more than happy 
> to pick up the thread started by James if the senior Django community sees 
> value in it! 
> 
> Cheers,
> Jonathon
> 
> 
> 
> On Tuesday, May 1, 2018 at 11:13:17 AM UTC-4, Jacob Kaplan-Moss wrote:
>> Great ideas, James. I totally agree we shouldn't rest on our laurels, and 
>> love the goal of pushing things forwards. Overall, I'm not sure a DEP is 
>> needed: each of these things is fairly small and tightly scoped, can be 
>> implemented on its own, and provides value independent of the whole. That 
>> seems like a scenario where just a bunch of loosely-related PRs makes the 
>> most sense. Added bonus: many of these things would be fairly easy pickings 
>> for a new contributor. If you wanted, you could delegate/coordinate some of 
>> this, and help us get more folks involved as a bonus.
>> 
>> Some comments on specifics:
>> 
>> On Tue, May 1, 2018 at 12:28 AM, James Bennett  wrote:
>>> Content Security Policy 
>> 
>> CSP is a tricky one. On the one hand, it's a tremendously effective defense 
>> against XSS. But, it's pretty tricky to get right: I've seen several sites 
>> struggle with a proper CSP config for years. It tends to be beyond the grasp 
>> of your classic one- or two-person dev team. When you get it wrong, it 
>> totally hoses your site. 
>> 
>> Most complex sites find they need to operate in report-only mode for a while 
>> and analyze the data before switching to enforce. And that requires a good 
>> reporting/analysis mechanism (something like report-uri.com, or a local 
>> equivalent). 
>> So all that to say: I highly support exploring this more, but it could be 
>> easy to turn CSP into a foot-gun. I don't think it's as easy as just 
>> shipping django-csp and calling it a day; we'd need to make sure it's not 
>> going to cause more problems than it solves.
>> 
>>> Referrer-Policy
>> 
>> +1, this seems like a no-brainer.
>> 
>>> 
>>> Subresource integrity
>> 
>> The jury seems to still be out on the value of SRI (at least, in my corner 
>> of the security community). It has some serious problems with dynamic 
>> assets, and with externally-hosted tools like Google Analytics. I'm not 
>> convinced that the current spec is fully-baked enough for us to support.
>> The admin's a special case since we tightly control what's shipped there; 
>> SRI-for-the-admin would be a nice, if incremental improvement. Preventing 
>> injection attacks in the admin is a very good thing :) 
>> 
>>> 
>>> CORS
>> 
>>  Yup, another no-brainer.
>> 
>>> rel="noopener"
>> 
>> I'm not sure I get this one, might need to see what you come up with to 
>> understand the effect.
>> 
>>> In my magical stretch-goal land, I'd also figure out a way to support
>>> the pyup safety library[8] to scan for a requirements file and any
>>> dependencies in setup.py, and warn if known-insecure versions are
>>> specified.
>> 
>> This seems entirely doable! Of course, grappling with the various options 
>> for dependency management might make this.. less fun 
>> (https://xkcd.com/1987/).
>> 
>> Jacob
> 

> --
>  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-developers+unsubscr...@googlegroups.com.
>  To post to this group, send email to django-developers@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/

Re: Proposal: security enhancements

2019-07-15 Thread James Bennett
On Mon, Jul 15, 2019 at 10:27 PM Curtis Maloney  wrote:

> I think there is certainly a strong case based on "secure by default" to
> include this in core, where it would otherwise face the "it works fine as a
> 3rd party app" barrier to entry.
>
> IMHO it would require, however, that the solutions be sufficiently generic
> as to not enforce an overly restrictive world view.
>
> I, for one, would be very interested to see more details here on what
> changes you propose.  Then, at least, we can keep a mailing-list history
> record of the discussion.
>

I had an attack of Real Life™ a while back which prevented following up on
this thread, but I have some thoughts I'd be happy to write up and share
here, and can at least try to find time to put in some work on
implementation.

I'll try to get something more detailed when the weekend rolls around
again, but the short version is that I'd like to spin up a third-party
project to do the implementation work in, and then look at integrating it
back into Django at a later time once it's been able to mature a bit.
That's been a successful model for a few other larger projects in the past,
and I think is also the right approach for doing this particular type of
security work, since there's still a decent amount of flux in the relevant
standards and their implementations (to take one example, the
Referrer-Policy header has had some consistency issues with browser
implementations) which would make me wary of putting it straight into
Django and enabled or even recommended by default.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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_LFUDGemLg7QYpcx-NKfhvc6U%3D3naaUz-YdTgt6G04RQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.