[Feedback requested] Django Debug Toolbar: Removal of automatic setup

[Matthias Kestenholz]

Hi everyone,

I wanted to solicit some feedback on the removal of automatic setup before moving forward with it. There's a pull request[1] by Jon Dufresne which removes the feature, and if anyone feels strongly about it now would be the time to speak up. The documentation encourages users to use the explicit setup, and automatic setup is only kept for backwards compatibility[2] therefore this change shouldn't be too surprising, at least for those reading the documentation.

Thanks,

Matthias

[1]: https://github.com/jazzband/django-debug-toolbar/pull/851

[2]: http://django-debug-toolbar.readthedocs.io/en/stable/installation.html#automatic-setup

[James Schneider]

An explanation as to 'why' you are removing it would have been helpful for this post for those who may use DDT, but are not intimately familiar with the documented intended deprecation. I noticed that Tim G. requested something similar in the PR.

From the docs, here is what I gathered:

https://django-debug-toolbar.readthedocs.io/en/stable/installation.html#automatic-setup

Warning

The automatic setup is known to interfere with the start-up sequence of some projects and to prevent them from loading or functioning properly.

The explicit setup described below is recommended for all but the most trivial projects. The automatic setup is kept for backwards-compatibility.

Note

The automatic setup imports your project’s URLconf in order to add the Debug Toolbar’s URLs. This is likely to trigger circular imports, for instance when the URLconf imports views that import models, a pattern found in almost every Django project.

If the development server crashes with a long stack trace after hitting an ImportError, anAppRegistryNotReady or an ImproperlyConfigured exception, use the explicit setup described below.

When the automatic setup is used, the Debug Toolbar is not compatible with GZipMiddleware. Please disable that middleware during development or use the explicit setup to allow the toolbar to function properly.

For me, the manual/explicit setup is simple enough that it won't serve as a barrier to use except by very new developers to Django itself. I believe all of my apps are currently using the automatic setup, but it wouldn't be too difficult to transition them to a manual setup. However, if you want to attract those first-time DDT users, the automatic setup is the way to go. It does make the app clean (to integrate) and pretty much brain-dead to implement. Bravo for that.

I would suggest three things:

1. If the maintenance of the existing code is not extensive and unwieldy (and it quite possibly is given the deep hooks DDT needs to gather the information required), I would ask for DDT to 'attempt' to auto-configure, and if it fails for any reason, have it fail out and indicate that a manual setup is needed. If the code for automatic integration is nasty and is slowing forward progress, then I'm also alright with getting rid of it to focus on other features related to the functionality of the toolbar itself.
2. Since the current stable docs do not mention a deprecation of the feature (only that it is kept around for backwards compatibility), I would recommend a deprecation message in the docs and run time warnings be displayed for automatic setups for a release cycle or two before the feature is actually removed, similar to how Django handles deprecation. Perhaps you can use a faster timeline since the DDT changes "shouldn't" affect production deployments, and if it does, well...
3. Not that I wish for more work for the Django devs, and I'm almost certain this has been brought up before, but the internal hooks and amount of useful information that this tool provides should make it a serious candidate for integration into Django itself. I don't know of any competing package, and Django does not readily/easily supply this information to the developer. Just a thought/wish...

Hope that helps, and excellent job on an excellent tool that I use constantly.

-James