Background
Proposal
"Just" start fresh with idiomatic Python-defined Django settings files.
There would be four new settings files:
lms/settings.pylms/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.
Background
Proposal
"Just" start fresh with idiomatic Python-defined Django settings files.
There would be four new settings files:
lms/settings.pylms/test_settings.py(derived fromlms/settings.py)cms/settings.py(derived fromlms/settings.py)cms/test_settings.py(derived fromcms/settings.pyandlms/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.pymodule, and then setDJANGO_SETTINGS_MODULEto point to the correct custom module in each environment. This is standard Django practice.Several things would be deprecated:
lms/envs/cms/envs/LMS_CFGandCMS_CFGBackwards 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/andcms/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.