We have a few Django settings which must match up with certain environment variables in order for edx-platform to generate and find assets correctly. This is because the non-app things which generate assets look at env vars, whereas in the in-app things that use assets look at Django settings. The static asset build rewrite is pushing forward this reality.
Both the Tutor and Paver take care of this for operators, in different ways:
- Tutor uses templates, so the operator specifies the setting once in their Tutor config, and Tutor renders it both into the environment and into Django settings.
- Paver uses a management command (
./manage.py [lms|cms] print_setting) to look up Django settings and inject them into environment variables. This suffers from the platform's slow startup time. Also, Paver-based asset builds are going away.
It'd be best if we didn't depend on either so that folks could stand up edx-platform on its own. Broadly speaking, I see two ways we can address this:
- Documentation (Django settings docstrings, edx-platform README).
- Load the Django settings based on environment variables.
Comment which brought up this ticket: #32804 (comment)
We have a few Django settings which must match up with certain environment variables in order for edx-platform to generate and find assets correctly. This is because the non-app things which generate assets look at env vars, whereas in the in-app things that use assets look at Django settings. The static asset build rewrite is pushing forward this reality.
Both the Tutor and Paver take care of this for operators, in different ways:
./manage.py [lms|cms] print_setting) to look up Django settings and inject them into environment variables. This suffers from the platform's slow startup time. Also, Paver-based asset builds are going away.It'd be best if we didn't depend on either so that folks could stand up edx-platform on its own. Broadly speaking, I see two ways we can address this:
Comment which brought up this ticket: #32804 (comment)