Greenfield prod-ready Django settings without YAML

Background

• https://github.com/openedx/open-edx-proposals/issues/587

Proposal

"Just" start fresh with idiomatic Python-defined Django settings files.

There would be four new settings files:

• lms/settings.py
• lms/test_settings.py (derived from lms/settings.py)
• cms/settings.py (derived from lms/settings.py)
• cms/test_settings.py (derived from cms/settings.py and lms/test_settings.py)

The recommended mechanism for configuring edx-platform would be to define a Django settings module for LMS and for CMS, each based on their respective settings.py module, and then set DJANGO_SETTINGS_MODULE to point to the correct custom module in each environment. This is standard Django practice.

Several things would be deprecated:

• all of lms/envs/
• all of cms/envs/
• yaml-based config via LMS_CFG and CMS_CFG

Backwards compatibility

Tutor would need to change significantly to adapt to this, but it could certainly be done, and possibly could be done in a way that doesn't break any patch points from the perspective of Tutor plugin devs and users.

Direct deployers of edx-platform would need to adapt. We would leave lms/envs/ and cms/envs/ in place for 6 months to allow for migration. After they are removed, direct deployers could still use them (and YAML config) by copying the settings modules they need into their private fork and/or deployment pipeline, and setting DJANGO_SETTINGS_MODULE accordingly.

Start by reading the linked Open edX proposal and then inspect the existing lms/envs/ and cms/envs/ configuration. Review how the proposed lms/settings.py, lms/test_settings.py, cms/settings.py, and cms/test_settings.py modules would replace YAML configuration while preserving the stated migration path for direct deployers and Tutor.