-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Remove automatic setup feature #851
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I'm going to make a release today to fix an incompatibility with a recent release of sqlparse. I'm not ready to make this change in a hurry, but it's still on the table. Perhaps you could bring the idea up on django-users? |
Current coverage is 76.86% (diff: 86.66%)@@ master #851 diff @@
==========================================
Files 30 30
Lines 1659 1634 -25
Methods 0 0
Messages 0 0
Branches 246 244 -2
==========================================
+ Hits 1253 1256 +3
+ Misses 327 302 -25
+ Partials 79 76 -3
|
|
||
# The following functions can monkey-patch settings automatically. Several | ||
# imports are placed inside functions to make it safe to import this module. | ||
# Several imports are placed inside functions to make it safe to import this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like only 1 function is left. Do you understand the comment? It's not clear to me who is doing the importing of this module.
@matthiask I think some of the doc changes from this commit were mistakenly included in 388e177. |
@jdufresne Oops. Thank you for the report! |
Request for comments: https://groups.google.com/forum/#!topic/django-users/no_yOMvFZ0M (no replies yet) Thanks for the feedback @timgraham! |
Thanks for the feedback. I believe I have addressed the issues raised. All additional feedback is welcome. I have tested the changes using the project's unit tests and against my own Django applications.
In the latest version I have moved
I adapted the warnings from the old installation docs. Those previous warnings are now listed as reasons for removing the automatic setup feature in the changes docs. Let me know what you think. |
debug_toolbar_index = None | ||
|
||
# Determine the indexes which gzip and/or the toolbar are installed at | ||
for i, middleware in enumerate(settings.MIDDLEWARE_CLASSES): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MIDDLEWARE should also be checked, not only MIDDLEWARE_CLASSES. (IMO the check could also be replaced by a big warning in the installation docs, but not sure whether that would be alright with everyone.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO the check could also be replaced by a big warning in the installation docs, but not sure whether that would be alright with everyone.
This already exists to some extent. From the installation docs Middleware section:
The order of
MIDDLEWARE_CLASSES
is important. You should include the Debug
Toolbar middleware as early as possible in the list. However, it must come
after any other middleware that encodes the response's content, such as
:class:~django.middleware.gzip.GZipMiddleware
.
Is this sufficient? Or would you like me to expand on this blurb? Or should I continue with modifying the runtime check?
I feel a bit bad making those judgement calls seeing as I'm not contributing to DDT for a long time (at all). But let's continue this :-) I very much prefer checking MIDDLEWARE first, since I don't think that removing the check removes much complexity from the codebase, and it's one stumbling block less when adding DDT to a project. |
|
Thank you! Now everything looks good to me. I'm not worried about the unsuccessful codecov/patch check in this case. Let's wait a working day or two for feedback on the mailing list and here on the pull request. I'll merge in case nobody brings up some good points why this shouldn't be done. Thanks again! |
I only just now realized that DDT includes an example project (for testing?). Would you like this updated as well to use the explicit setup? Should be easy to update. |
Yes, the example project is for manual testing and should be updated to reflect whatever the documentation recommends. |
Thanks. The example project has been updated to current Django and DDT configuration recommendations. |
check_middleware() | ||
|
||
|
||
def check_middleware(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If not too complicated, that might be a candidate for using the system check framework.
The middleware check was moved to apps.py and changed to use the system checks framework. It was updated to check MIDDLEWARE in addition to MIDDLEWARE_CLASSES. It now checks that DebugToolbarMiddleware occurs in one of the settings. Updated installation documentation to reflect new requirements. The bundled example project was updated to current Django and Debug Toolbar configuration recommendations. Fixes #838
Great idea! I have updated the change to use system checks. I also added a test for these systems checks so codecov is happy again. I made other suggested changes as well. Thanks! |
Fixes #838