| published by | Software Crafts |
|---|---|
| in blog | Software Crafts |
| original entry | What is the future of `django.contrib`...? |
In my last post, I had some questions about the contrib namespace with in Django core. I also answered a few of them, today I'm going to continue answering the rest of them.
The next group of questions were about whether any of the packages should move out or in of contrib or just remain in contrib. After writing my post on Friday, I had some reflections on what makes packages in contrib unique, first they are the only Django apps inside core, ie they need to be specified inside INSTALLED_APPS, some have migrations etc.. they also shouldn't be essential to every Django project in existance. This second point is hard to pin down since Django doesn't collect usage statistics of any kind, but a fair number of contrib packages are included by default.
The second major aspect I considered was the dependencies both with in the contrib namespace and with contrib and the rest of the Django codebase. Using the Impulse CLI I mapped the the internal dependencies which can be seen below. This illustrates an interesting point, that some packages depend on each in different ways (admin & auth) and also some packages which would be considered essential today (eg auth) depend on packages considered more optional (sites & contenttypes). The final aspect of looking at this diagram is that perhaps the packages with no links could be moved (eg sessions or humanize) or those that depend on no other packages (staticfiles and messages). What is clear is that there isn't an easy answer for every package within contrib

Looking at the dependencies with other parts of the Django codebase, there are two main dependencies. staticfiles depends on django.test and django.templatetags and auth depends on django.test. To me this elevates staticfiles to be a candidate for migrating into core fully as it's has no dependencies within contrib and has 'external' dependencies.
However for most of the oher packages within contrib I think they need to stay where they are, or any moves need to considered along with there dependencies. The alternative is to perhaps breaks an app up so parts live in different packages within core?
The above in part answers the question, that contrib still has a place in Django, but finally how do we as a community add a new package to contrib? Could contrib be a place to experiment with new batteries for Django? Is it a place for select 'first-party' packages? Could it be a place for faster experimentation? Can we our cake and eat it? I'll explore more about this tomorrow.