Repository navigation
Collapse the FEATURES dictionary into boolean settings #36890
Description
Both LMS and CMS settings have a big FEATURES dictionary. The values are all booleans.
There are also many boolean settings outside of the FEATURES dictionary.
It adds unnecessary complexity to have so many booleans stuffed into one FEATURES dictionary. It makes these values harder to override individually, both in unit tests and in the settings files themselves. There is no particular reason why these are in a dictionary.
Goals:
- Flatten the keys of FEATURES into the settings namespace
- Update all references in edx-platform
- Create a proxy FEATURES dictionary which allows external code to seamlessly read and write these settings as is they were still part of the FEATURES dictionary.
Metadata
Metadata
Assignees
Labels
No labels
Activity
kdmccormick commentedon Jun 10, 2025
@wgu-taylor-payne
robrap commentedon Jun 10, 2025
@kdmccormick: It sounds like the last bullet, the proxy idea, is part of an expand phase. Are you hoping to have a contract as well? I don't think this necessarily needs a DEPR, but you may want to consider just if you want to use the inform process.
One question about DEPR process vs refactors, are whether we can get tickets through with auto-acceptance for expansion (like in cases where we were going to skip DEPR anyway), and then just negotiate possible contract timeline.
This is all food for thought. Maybe a DEPR comes later just for the proxy if you ever want to initiate removal?
kdmccormick commentedon Jul 21, 2025
This is exactly my thinking. We can go ahead with the refactoring now as long as we ensure it's non-breaking. If we want to "contract" later, then we could make a DEPR ticket whose transition is immediately ready.
wgu-ram-chandra commentedon Jul 23, 2025
Hi @kdmccormick,
I've been working on this issue, and before opening a PR, I wanted to check in to make sure I'm heading in the right direction and that this approach aligns with your expectations.
Regarding the three steps mentioned:
FEATURESdictionary, used in various formats such assettings.FEATURES.get("KEY", value)andwith override_settings(FEATURES={'KEY': value}). I’ve written a Python script to help migrate these to use the flattened settings structure.What would you think would be the best next step from here?
Thanks!
kdmccormick commentedon Jul 23, 2025
@wgu-ram-chandra Your approach so far sounds great to me! I would open a PR now and see whether tests pass. If you're uncertain whether it's ready for final review and merge, that's totally fine, just open it as a "Draft". I can take a look and let you know with more confidence whether or not you're heading in the right direction.
wgu-ram-chandra commentedon Jul 25, 2025
Hi Kyle, I've created a draft PR(#37067). All tests are passing and I've also included a multi-PR plan. Could you please review when you have a chance and let me know if you're comfortable with the proposed multi-PR strategy?
Looking forward to hearing your thoughts!
Thanks!
robrap commentedon Sep 18, 2025
@feanil @kdmccormick: Where do you plan to track the future work documented in the DEPR? Thanks.
FEATURES = FeaturesProxy(...)to your django settings #37345kdmccormick commentedon Sep 29, 2025
@robrap Right here: #37396
We'll properly announce it when the details are ironed out.