Django core depends on django.contrib

[Piotr Lewandowski <django@…>]

I believe that it should be possible to strip django/contrib directory and still have a functional Django. However, currently there are some imports from django.contrib present in non-contrib part of Django. It's contrary to the ​loose-coupling idea and ​description of contrib package (a variety of extra, optional tools).

$ egrep -ohr --include='*.py' --exclude-dir=contrib --exclude-dir=conf 'django[.]contrib[.][[:alnum:]]+' django-trunk/django/ | sort | uniq -c | sort -n
      2 django.contrib.localflavor
      2 django.contrib.sites
      3 django.contrib.sessions
      4 django.contrib.contenttypes
      5 django.contrib.auth

$ egrep -lr --include='*.py' --exclude-dir=contrib --exclude-dir=conf 'django.contrib.[[:alnum:]]+' django-trunk/django/
django-trunk/django/test/client.py
django-trunk/django/db/models/sql/subqueries.py
django-trunk/django/db/models/fields/__init__.py
django-trunk/django/db/models/base.py
django-trunk/django/core/management/commands/cleanup.py
django-trunk/django/core/management/sql.py
django-trunk/django/core/context_processors.py
django-trunk/django/views/generic/create_update.py
django-trunk/django/views/defaults.py
django-trunk/django/middleware/cache.py

[Piotr Lewandowski <django@…>]

Dependency on django.contrib.localflavor is already covered by #8210 and #8664.

[James Bennett]

I suspect many of these are not what you think they are, or involve optional features of core functionality (e.g., generic views use auth for optional "login required" functionality).

[Piotr Lewandowski <django@…>]

Replying to ubernostrum:

I suspect many of these are not what you think they are, or involve optional features of core functionality (e.g., generic views use auth for optional "login required" functionality).

Why generic views should even know anything about auth-related stuff? After all, we have login_required decorator in django.contrib.auth.decorators which should handle it. Now this same job is done by two distinct pieces of code - looks like ​DRY violation to me.

[Piotr Lewandowski <django@…>]

Backwards compatibile issues

tests/client.py

Presence of django.contrib.session in INSTALLED_APPS is mostly checked before import. It can be done with django.contrib.auth as well, which is actually used only in Client.login() method. Or at least relevant import could be just moved to this method (ugly).

db/models/sql/subqueries.py

django.contrib.contenttypes is used in DeleteQuery.delete_batch_related() method. At least a check in INSTALLED_APPS could be done.

core/management/commands/cleanup.py

Move this command to django/contrib/session/management/commands/.

core/management/sql.py

Import is present but not used. Remove it.

views/defaults.py

Additional check for django.contrib.contenttypes and django.contrib.sites in INSTALLED_APPS.

Backwards incompatible issues

django/db/models/fields/__init__.py

Covered by #8210 and #8664.

views/generic/create_update.py

create_object() should not have login_required argument. django.contrib.auth.decorators.login_required should be used instead.

core/context_processors.py

Move django.core.context_processors.auth to django.contrib.auth.context_processsors.

No issues

db/models/base.py

django.contrib used only in a comment.

middleware/cache.py

django.contrib used only in an assertion string.

[Adrian Holovaty]

We've discussed this at DjangoCon (independently of this ticket) and decided it would be a good plan to refactor things so that django.contrib could be safely deleted without affecting the rest of the framework. I have not looked at the patches in this particular ticket, but I'm marking the ticket as accepted because we like the concept.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Running the command provided by the OP I still found the following uses of contrib in core.

Action needed:

1. django/middleware/doc.py: checks request.user.is_active/is_staff
2. django/test/client.py: depends on django.contrib.auth (at least)
3. django/test/testcases.py: depends on django.contrib.staticfiles (at least)
4. django/views/defaults.py: shortcut has a comment saying it should be deprecated in Django 2.0, but I don't see much point in waiting; we have a well established deprecation policy now and this is a trivial case.

No action needed:

1. django/core/management/commands/cleanup.py: it's deprecated
2. django/db/models/base.py: it's just a comment
3. django/middleware/cache.py: tests request.user.is_authenticated() when CACHE_MIDDLEWARE_ANONYMOUS_ONLY is set. #15201 proposes to decouple CACHE_MIDDLEWARE_ANONYMOUS_ONLY from django.contrib.auth by testing only if the response varies on cookie. That covers the issue.

[Aymeric Augustin]

3f2befc93163e0666dcc4f745288b98306de4b8e addressed action 4.

[Aymeric Augustin]

I filed #20126 for action 1.

[Ramiro Morales]

I filed #20739 for item 3.

[Ramiro Morales]

I filed #20915 for item 2.

[Aymeric Augustin]

Since all changes identified in comment 13 have been done, except the one that's still tracked in #20915, I believe we can close this ticket.