FAQ | This is a LIVE service | Changelog

fix(deps): update dependency django-debug-toolbar to v6 - autoclosed

uis-devops-renovatebotrequested to merge
renovate/django-debug-toolbar-6.x into main

This MR contains the following updates:

Package Change Age Confidence
django-debug-toolbar (changelog) 5.2.0 -> 6.0.0 age confidence

Release Notes

django-commons/django-debug-toolbar (django-debug-toolbar)

v6.0.0

Compare 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_id then it will be backwards incompatible.

Third-party panels will need updating. Any data that is stored in record_stats will need to be fetched back out from self.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 in debug_toolbar/panels/cache.py in MR 2138

How to upgrade
  • Changes required if the toolbar isn't installed entirely programmatically
    • If you experience 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 your urls.py file and MIDDLEWARE setting when the toolbar isn't in INSTALLED_APPS
  • If you have a custom panel, you'll need to adjust record_stats and use self.get_stats() to fetch data for rendering
  • If you'd like to use the database store, see TOOLBAR_STORE_CLASS for more info
Why 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: https://github.com/django-commons/django-debug-toolbar/compare/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.

Configuration

📅 Schedule: Branch creation - Monday through Friday ( * * * * 1-5 ) in timezone Europe/London, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻️ Rebasing: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this MR and you won't be reminded about this update again.

  • If you want to rebase/retry this MR, check this box

This MR has been generated by Renovate Bot.

Edited by uis-devops-renovatebot

Merge request reports