I want to offer a reframe that I think could unlock more progress here. I saw today’s updates from Andy in the draft DEP and those prompted me to engage.
In my view, the most valuable outcome of this project is a solid feature flags framework that any Django project can use. Django itself may end up being one user of it, but it should not be the primary design constraint.
A general-purpose feature flags framework is a much stronger contribution. It solves a real problem for the whole ecosystem, and existing options like waffle and django-flags are not in great shape. This is something I’d be happy to assist with and support.
I think Carlton and Jacob have been pointing at this, and I want to say it more directly: the energy here is better spent building something the whole community can use. Visibility and discoverability are real problems, and a general-purpose framework is a better investment than an experimental switch inside core.
PS: I’ve been sitting with this for a while, not sure how to share my perspective without being discouraging (also I get some anxiety thinking about the practical consequences for the Fellows). Enabling an experimental option inside Django is not sustainable given current bandwidth: any such space would attract contributions that then require triage, review, and maintenance, and we are already at capacity.
1 Like
Waffle has always seemed fine to me… — is the issue that it’s unmaintained?
(And would a new option have any guarantee of being maintained? — It that the missing why core?)
My concern is less about maintenance and more about internal design and smooth integration, what the API can and can’t do cleanly. I’ve used waffle in production in the past and the friction around dynamic state (flags evaluated inside or outside a request context, in tasks or management commands) was real and not incidental.
That said, whether a feature flags framework belongs in core is a separate and genuinely open question, though I do think there is a real case to be made. A feature flags implementation that works naturally across Django’s own verticals (auth, ORM, middleware, tasks, templates) likely needs something from core that third-party packages can’t easily reach.
I’d love to see this GSoC project do that research: what would a solid implementation actually need from Django internals, and is that need strong enough to justify a home in core? Django (as a client) is a demanding/complex enough that designing for it well would cover most real-world needs, I think.
1 Like
I could see shifting the project that dramatically at this point being a bit of a sticking point.
Setting that aside, I’m curious if there’s any merit to trying to support companies who have restrictive dependency environments. I’m thinking of those organizations who can only use dependencies that are stable/well-maintained, etc. Would our approach of all features and experiments as an ecosystem, only going through third-party projects prohibit their participation and feedback?
For community awareness, today we met the Fellows, the Steering Council, and Andy, and we talk through this agreeing on next steps.
In my experience, those environments tend to lock down everything including the Django version itself: upgrades require the same vetting and security reviews as any new dependency. Runtime flag flipping would likely be treated as a configuration change with its own approval process. So I’m not sure we’d get meaningful feedback from them regardless of where the feature lives.
That said, I’m thinking of the most restricted setups. If others have seen a middle ground where teams stay current with Django but avoid unvetted third-party packages, I’d be eager to hear it.
1 Like
Thank you everyone for all the feedback and guidance during the discussions.
While the discussions on Experimental Framework were going on, @nanorepublica and I were working on the proof of concept for how an experimental space would work in Django.
We released django-experimental as a prototype, and it also has an updated user model with full name, unique email and login with username or email.
Links:
I would love for everyone to try it out and share feedback.
Also, since the project was reframed to feature flags framework, we built django-featurevault, details for which I have shared in the new thread.
It would be great if everyone could take a look at both and share their views.
I’m a bit skeptical of the dynamic settings approach. Though it is in line with the new feature idea to use Pluggy to simplify settings.
It does also avoid having the user change settings again if an adjustment is needed. Though similarly, an update to how this package configures the settings would silently update a project’s settings if that project already had enabled that experiment.