The method included to patch get_query_set is very broken, and leads to some very bug code in circumstances where managers get subclassed - the behaviour of the subclass can be skipped. This is a very serious error for the case of Related managers, because it means that the limiting of the queryset that is added by the subclass get_query_set method gets skipped, so the related manager queries apply to all objects.

I've created a branch that demonstrates the problem, adding 4 tests, 2 of which fails with Django 1.8, one fails with Django 1.5:

https://github.com/spookylukey/django-compat/tree/get_query_set_patch_bug

I've created a PR so that you can see the tests failing.

The full details are explained in this blog post:

http://lukeplant.me.uk/blog/posts/handling-django's-get_query_set-rename-is-hard/

I think use django-nose is a bad idea because it doesn't support Django<1.8. So we cannot test this version with the ./runtests.py.

We should use Django test runner like made here: https://github.com/django-dbbackup/django-dbbackup/blob/master/runtests.py It also allow to launch any commands like manage.py.

Hello,

i'm planning a sprint at pyconfr to build a django compatibility module, which wouldn't behave like an intermediate module (like six for py3k, or like django-compat for django), but directly monkey-patch django with log-lifespan shims.

Thus, django webmaster who want to upgrade wouldn't have to fork/monkeypatch all their broken dependencies, and minor django upgrades would REALLY be minor (i.e would NOT rename/remove methods and attributes used by tons of unmaintained libs).

Would you be OK with integrating this monkey-patching utility to django-compat, to have an all-in-one solution, for BOTH library maintainers and library users ?

• http://django.readthedocs.org/en/latest/topics/templates.html#django.template.loader.render_to_string

• based on https://github.com/mysociety/mapit/blob/master/mapit/djangopatch.py#L4-L12

  """ Django 1.8 changed how templates operate. """
  import django
  if django.get_version() >= '1.8':
      from django.template.loader import render_to_string
  else:
      from django.template import loader, RequestContext
  
      def render_to_string(template_name, context=None, request=None):
          context_instance = RequestContext(request) if request else None
          return loader.render_to_string(template_name, context, context_instance
  

   File "/var/www/.virtualenvs/ditchcity/local/lib/python2.7/site-packages/django/db/models/loading.py", line 72, in _populate
     self.load_app(app_name, True)
   File "/var/www/.virtualenvs/ditchcity/local/lib/python2.7/site-packages/django/db/models/loading.py", line 94, in load_app
     app_module = import_module(app_name)
   File "/var/www/.virtualenvs/ditchcity/local/lib/python2.7/site-packages/django/utils/importlib.py", line 35, in import_module
     __import__(name)
   File "/var/www/.virtualenvs/ditchcity/local/lib/python2.7/site-packages/compat/__init__.py", line 42, in <module>
     from six.moves._thread import get_ident  # noqa
 ImportError: No module named _thread

ubuntu@staging:~$ python --version
Python 2.7.6

  File "/Users/Bruno/Documents/Workspace/open-source-projects/django-surveys/.tox/py36-djangomaster/lib/python3.6/site-packages/compat/__init__.py", line 388, in <module>
    from django.urls import (
ImportError: cannot import name 'LocaleRegexProvider'

From the updates in the tests in this PR, I'm under the impression that it was renamed to RegexPattern in Django 2.0a1.

Django 1.11 LTS will be the last Django version to support Python 2. The next major release, Django 2.0, will only support Python 3.5+. So Django 1.11.x will probably be the last supported version for LTS-to-LTS support of django-compat (1.8-1.11). See Django's release notes for more.

This GitHub project doesn't mention Django 1.10 in the blurb:

It needs to match the README file.

This also affects the blurb in https://djangopackages.org/packages/p/django-compat/

$ ./bin/pip --version
pip 8.0.2 from /webapps/planexo/lib/python3.4/site-packages (python 3.4)

$ ./bin/pip install django-compat
Collecting django-compat
  Using cached django-compat-1.0.8.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "/tmp/pip-build-1wztbpt3/django-compat/setup.py", line 33, in <module>
        long_description=read('README.rst')
      File "/tmp/pip-build-1wztbpt3/django-compat/setup.py", line 17, in read
        return open(get_path(fname)).read()
    FileNotFoundError: [Errno 2] No such file or directory: '/tmp/pip-build-1wztbpt3/django-compat/README.rst'

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-1wztbpt3/django-compat/setup.py", line 36, in <module>
        long_description=read('README.md')
      File "/tmp/pip-build-1wztbpt3/django-compat/setup.py", line 17, in read
        return open(get_path(fname)).read()
      File "/webapps/planexo/lib/python3.4/encodings/ascii.py", line 26, in decode
        return codecs.ascii_decode(input, self.errors)[0]
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 8678: ordinal not in range(128)

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-1wztbpt3/django-compat

NB: This includes the Tox support added by #32

• Fix compat.get_ident() on Python 3.2
• Fix compat.tests.test_compat.CompatTests.test_compat() on Python 2.6
• Fix compat.tests.test_compat.CompatTests.test_format_html() on Python 2.6

NB: This doesn't include Python 2.5, even though it's supported by Django 1.4

These points should be better communicated in the README

• [x] what version of Django is supported and unsupported anymore
• [ ] Version convention from django-compat to Django

Please note #17 as well that aims to show what works in wich version and if its tested.

Tests fail with

  File "/home/abuild/rpmbuild/BUILD/django-compat-1.0.15/compat/tests/urls.py", line 5, in <module>
    url(r'^accounts/logout/$', views.logout, name='logout'),
AttributeError: module 'django.contrib.auth.views' has no attribute 'logout'

Fairly simple to fix https://stackoverflow.com/questions/47065438/attributeerror-module-django-contrib-auth-views-has-no-attribute

The lack of this creates dependency problem as provided by setup.py.

See the following Debian bugs:

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896337
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896205

The next version of Django is changing quite radically the way URLs are being included, by requiring an app name to be provided. One way to do it (and sometimes the only one) is to change the first parameter to a tuple.

It would be great if there could be a version of include in django-compat. It looks like the new syntax is available from 1.9, and the old syntax is no longer working from 2.0.

Would that be an acceptable change? I could try to put together a PR if so.