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