Skip to content

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

Merged
merged 1 commit into from
Aug 23, 2016
Merged

Remove automatic setup feature #851

merged 1 commit into from
Aug 23, 2016

Conversation

jdufresne
Copy link
Contributor

Fixes #838

@aaugustin
Copy link
Contributor

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?

@codecov-io
Copy link

codecov-io commented Aug 19, 2016

Current coverage is 76.86% (diff: 86.66%)

Merging #851 into master will increase coverage by 1.33%

@@             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   

Powered by Codecov. Last update d27f4ff...fe74d9b


# 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
Copy link
Contributor

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.

@jdufresne
Copy link
Contributor Author

jdufresne commented Aug 20, 2016

@matthiask I think some of the doc changes from this commit were mistakenly included in 388e177.

@matthiask
Copy link
Member

@jdufresne Oops. Thank you for the report!

@matthiask
Copy link
Member

Request for comments: https://groups.google.com/forum/#!topic/django-users/no_yOMvFZ0M (no replies yet)

Thanks for the feedback @timgraham!

@jdufresne
Copy link
Contributor Author

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.

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.

In the latest version I have moved check_middleware() to apps.py. This is the only file that calls this function. Moving it allowed me remove the imports inside the function; they are now at the top level. I removed the comment entirely as I feel it is no longer relevant.

It would be nice to explain why it's been removed.

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):
Copy link
Member

@matthiask matthiask Aug 20, 2016

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.)

Copy link
Contributor Author

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?

@matthiask
Copy link
Member

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.

@jdufresne
Copy link
Contributor Author

  • Updated the runtime check to handle MIDDLEWARE
  • Updated the runtime check to warn on the absence of DebugToolbarMiddleware (as it is no longer added automatically)
  • Updated the warning wording based on removal of automatic setup
  • Emphasized the GZipMiddleware documentation as a "warning"

@matthiask
Copy link
Member

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!

@jdufresne
Copy link
Contributor Author

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.

@aaugustin
Copy link
Contributor

Yes, the example project is for manual testing and should be updated to reflect whatever the documentation recommends.

@jdufresne
Copy link
Contributor Author

Thanks. The example project has been updated to current Django and DDT configuration recommendations.

check_middleware()


def check_middleware():
Copy link
Contributor

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
@jdufresne
Copy link
Contributor Author

jdufresne commented Aug 21, 2016

If not too complicated, that might be a candidate for using the system check framework.

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!

@matthiask matthiask merged commit fe74d9b into django-commons:master Aug 23, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants