Collapse the FEATURES dictionary into boolean settings

[kdmccormick]

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.

[kdmccormick]

@wgu-taylor-payne

[robrap]

@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]

Maybe a DEPR comes later just for the proxy if you ever want to initiate removal?

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]

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:

1. Step 1 is complete, I’ve flattened the keys and retained the existing naming convention without adding any prefixes or suffixes.
2. Step 2 involved identifying over 1500+ references to the FEATURES dictionary, used in various formats such as settings.FEATURES.get("KEY", value) and with override_settings(FEATURES={'KEY': value}). I’ve written a Python script to help migrate these to use the flattened settings structure.
3. Step 3 is also complete, I’ve created a proxy that currently supports access from different plugins.

What would you think would be the best next step from here?

Thanks!

[kdmccormick]

@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]

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]

@feanil @kdmccormick: Where do you plan to track the future work documented in the DEPR? Thanks.

• [DEPR]: Add FEATURES = FeaturesProxy(...) to your django settings #37345