Opened 8 years ago

Closed 3 years ago

#8713 closed New feature (fixed)

Django core depends on django.contrib

Reported by: Piotr Lewandowski <django@…> Owned by: nobody
Component: Core (Other) Version: master
Severity: Normal Keywords:
Cc: jwilk@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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

Attachments (3)

core-management-sql.diff (523 bytes) - added by Piotr Lewandowski <django@…> 8 years ago.
core-management-commands-cleanup.diff (1.7 KB) - added by Piotr Lewandowski <django@…> 8 years ago.
test-client.diff (1.4 KB) - added by Piotr Lewandowski <django@…> 8 years ago.

Download all attachments as: .zip

Change History (21)

comment:1 Changed 8 years ago by Piotr Lewandowski <django@…>

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

comment:2 Changed 8 years ago by 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).

comment:3 in reply to:  2 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by 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.

comment:5 Changed 8 years ago by Piotr Lewandowski <django@…>

Owner: changed from nobody to pl

Changed 8 years ago by Piotr Lewandowski <django@…>

Attachment: core-management-sql.diff added

Changed 8 years ago by Piotr Lewandowski <django@…>

comment:6 Changed 8 years ago by Piotr Lewandowski <django@…>

Owner: changed from pl to nobody

Changed 8 years ago by Piotr Lewandowski <django@…>

Attachment: test-client.diff added

comment:7 Changed 8 years ago by Piotr Lewandowski <django@…>

Component: UncategorizedCore framework

comment:8 Changed 8 years ago by Adrian Holovaty

Triage Stage: UnreviewedAccepted

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.

comment:9 Changed 6 years ago by Jakub Wilk

Cc: jwilk@… added
Easy pickings: unset
Severity: Normal
Type: Uncategorized

comment:10 Changed 6 years ago by ubanus@…

Cc: ubanus@… removed

comment:11 Changed 6 years ago by Luke Plant

Type: UncategorizedNew feature

comment:12 Changed 5 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:13 Changed 4 years ago by 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 and has coupling with 'django.contrib.sessions'
  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.
Version 2, edited 3 years ago by Ramiro Morales (previous) (next) (diff)

comment:14 Changed 4 years ago by Aymeric Augustin

comment:15 Changed 4 years ago by Aymeric Augustin

I filed #20126 for action 1.

comment:16 Changed 3 years ago by Ramiro Morales

I filed #20739 for item 3.

Last edited 3 years ago by Ramiro Morales (previous) (diff)

comment:17 Changed 3 years ago by Ramiro Morales

I filed #20915 for item 2.

comment:18 Changed 3 years ago by Aymeric Augustin

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top