chore(deps): update dependency django-debug-toolbar to v6 #3203
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
^4.1.0→^6.0.0Release Notes
django-commons/django-debug-toolbar (django-debug-toolbar)
v6.1.0Compare Source
What's Changed
See change log here
Commits:
debug_toolbar_urlsto inside of … by @Lidoca in #2174New Contributors
Full Changes: django-commons/django-debug-toolbar@6.0.0...6.1.0
v6.0.0Compare Source
Description
The v6.0.0 release of Django Debug Toolbar significantly revamps how panels for the toolbar work. Each panel will now persist its data in a store. A store can either be backed by various backends. The toolbar will support a memory and database backend to start.
The toolbar is now using Django's
SafeExceptionReporterFilter.cleanse_setting()function to filter out sensitive information. Some data will be replaced with"********************". This is because the toolbar could be configured to write the request information to a persistent store such as a cache or database.Django applications with basic installations are backwards compatible with this change. If there are hooks into the internals of the toolbar, such as
DebugToolbar.store_idthen it will be backwards incompatible.Third-party panels will need updating. Any data that is stored in
record_statswill need to be fetched back out fromself.get_stats()before being able to be rendered. This is to support loading an instance of the toolbar from persisted data. A simple example of this transition can be found indebug_toolbar/panels/cache.pyin PR 2138How to upgrade
RuntimeError: Model class debug_toolbar.models.HistoryEntry doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS, you need to remove the reference to the toolbar's urls in yoururls.pyfile andMIDDLEWAREsetting when the toolbar isn't inINSTALLED_APPSrecord_statsand useself.get_stats()to fetch data for renderingTOOLBAR_STORE_CLASSfor more infoWhy did the internals change?
The Django Debug Toolbar is a popular package we did not want to block the community from pursuing the async path for Django applications. Writing the request data to a store better positions the toolbar for async projects. It also opens the door for it being usable in production as well with API integrations.
What's Changed
Full Changelog: django-commons/django-debug-toolbar@5.2.0...6.0.0
Acknowlegements
Thank you to all the contributors who made this release possible. Thank you to @robhudson, @matthiask, @tim-schilling, @salty-ivy and @dr-rompecabezas for their support, development and reviews of the serializable toolbar changes. A special shout-out to @matthiask for leading the Djangonaut Space Session 4 team of @dr-rompecabezas, @andoriyaprashant and @blingblin-g.
v5.2.0Compare Source
What's Changed
New Contributors
Full Changelog: django-commons/django-debug-toolbar@5.1.0...5.2.0
v5.1.0Compare Source
What's Changed
New Contributors
Full Changelog: django-commons/django-debug-toolbar@5.0.1...5.1.0
v5.0.1Compare Source
What's Changed
There were no functional changes in this version.
PRs
Full Changelog: django-commons/django-debug-toolbar@5.0.0...5.0.1
v5.0.0Compare Source
What's Changed
Please note that Django Debug Toolbar has now moved into the Django Commons organization.
Changelog
strstatic file values.Google Summer of Code Project 2024 <https://summerofcode.withgoogle.com/programs/2024/projects/iXVvyGYp>__.LoginRequiredMiddlewareintroduced in Django 5.1.UNIONqueries on PostgreSQL.FORCE_SCRIPT_NAMEwas set.RedirectsPanelto be async compatible.sorted.
PRs
FORCE_SCRIPT_NAMEby @dmartin in #1970DEBUG=Truein async middleware compatibility tests by @salty-ivy in #1977StaticFilesPanelby @salty-ivy in #1983HistoryPanelby @salty-ivy in #1991SQLPanelby @salty-ivy in #1993Google Summer of Code - Async project
This release contains the changes for async compatibility for the majority of panels. This is the result of the Google Summer of Code project by @salty-ivy. A massive thank you 💚 and a round of applause 👏 is due to Aman!
New Contributors
Full Changelog: django-commons/django-debug-toolbar@4.4.6...5.0.0
Configuration
📅 Schedule: Branch creation - "every weekend" in timezone US/Eastern, Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.