Share how you use Django with Django Probe

For a while I’ve had this idea of projects sharing how they used Django. In Chicago at DjangoCon US, I pitched the idea of a package that looked for particular coding patterns and shared them back to a central hub. An example would be checking to see if the @cache_page decorator was used in a repository and how often¹. It was met with a lot of “Oh. Yeah. That’s a good idea; we should do that” responses.

So coming home, I had a bunch of energy and decided to implement Django Probe². It allows you to share how you use Django with the community so the community can make better decisions. It’s a low-effort, high-impact way to support the community from a technical perspective.

You can get started with the package on the website, read the documentation for more details, or review the code on the repository.

Once you sign up, create a project token and install the package, you can share how you use Django.

export DJANGO_PROBE_TOKEN=<your_project_token>
django-probe scan . # Review the payload first
django-probe submit . # Share with the community

Why I think this is cool

I did a very early preview of the package at a DSF Office Hours³, and Jeff Triplett gave me some excellent feedback. He pointed out that we shouldn’t limit ourselves to particular predefined patterns and instead should count up all the Django classes, methods, and function usages.

That was a floodgate opening for me.

Being able to see, in aggregate, how the Django framework gets used would be immensely useful to maintainers and community members. As a Steering Council member, it would be very helpful to see how many people are using a particular function. For example, the QuerySet.extra() method has been sort of deprecated for years. It would have been great to see how the usage of this tracked over the years. If we had data from just today, we could see if it’s being used at all, in what size of projects, and for what versions of Django. While still far from perfect, that bit of information would be helpful.

Currently, decisions are made based on gut feelings or anecdotal stories from personal networks. It functions, but there’s so much gray area. It forces us to move cautiously and slowly, for better or worse. Let’s take a look at how this plays out in two places: how Django decides what to build, and how the community decides where to focus its effort.

How this shapes the feature process

Usage analytics could be just as valuable for deciding what Django adds as what it removes, and slimming the framework down, exciting as that is, is only half the story. While not configured today, there’s nothing stopping Django Probe from being used with non-Django packages⁴.

Let’s take auth for example. That’s been a hot topic for the last, what, decade or so? There are some people who believe Django should have support for MFA out of the box. We could ask people to configure their Django Probe configuration to share data on third-party projects like django-allauth. From there, we could see, out of the X projects using django-allauth, how many are using MFA? How many projects does this represent out of all Django projects that are sharing data? Maybe the choice of authentication depends on the project’s circumstances. So perhaps we can check if the number of files in the project impacts how authentication is handled.

This could be a source of objective data for the community, Steering Council, and Fellows to factor into their decision-making.

How this focuses community effort

The other place this helps the community is determining where we need more documentation, tutorials, and talks. For example, the models.Field.contribute_to_class() is an officially undocumented feature of Django. While there have been blog posts about it for the past 15 years from prominent community members, it’s not clear whether this should be documented or not. If people still aren’t using contribute_to_class() it’s at least worthy of a few more blog posts or conference talks. Or if a significant chunk of the community is using it, we should consider documenting it so that we protect its API with our deprecation policy, ensuring stability for developers.

What still remains

Django Probe is still under active development. However, since it can be treated as a linter (it’s just uvx django-probe submit .), it can be a separate CI action that runs outside your development flow. Long-term, setting it up to share once a month should be sufficient. Sharing more frequently to help me identify bugs would be appreciated, though.

Currently, the project only accepts data. It’s not rendering any data out. At the time of writing this, 11 projects are sharing information. That’s enough for me to tackle the task of building out some basic reporting features. However, the more advanced features, like analyzing data on a particular set of facets, will require many more projects sharing information.

So there are two places you can get involved:

1. Create an account to start sharing how your project(s) use Django
2. Contribute to the package