LET: a Tutor plugin to simplify Open edX customization

TL;DR
LET is a Tutor plugin that simplifies customization of Open edX. It not only lets you configure +200 settings in a very simple way, but can also show all the available settings and their default values so you can know the many things you can do with your platform. In its PyPI home page, all available settings are explained.

Motivation
Have you ever wondered why is it so hard to make BASIC customizations to Open edX?

One of the reasons why is because many parameters have to be set using Django’s settings module, which requires you to change some files in the system. There is no way to do it from the platform’s web interface.

These settings reside as configuration files lms.env.yml and cms.env.yml, in yaml format, for the LMS and Studio. But the settings can also be modified, in python format, editing the production.py and development.py files (a pair for the lms and another for the cms). Some settings are inside an entry in the settings module called “FEATURES”. To tell if what you want to do is inside FEATURES or not, you will have to check the documentation or dive into the code. Not only that: some features have to be enabled using a waffle flag, or a waffle switch. And some others need a special setting in the Django admin page.

Additionally, to make persistent changes using Tutor you should not edit the files inside the env directory: they will be rewritten after doing tutor config save. Even if you find out which setting variable you want to change, just adding that to the config.yml file won’t work. Instead you have to write a Tutor plugin and patch one of the files (after you figure out which file to patch).

Installation
To install just run:

pip install tutor-contrib-let
tutor plugins enable let

How it works
The LET Tutor plugin adds two sub-commands to Tutor: tutor let and tutor list. Let me illustrate with an example:

To disable email validation at registration, run:

tutor let SKIP_EMAIL_VALIDATION=true

This will add the following line to config.yml:

LET_SKIP_EMAIL_VALIDATION: true

and will modify the appropriate file to make this change persistent.
To see all the settings you have made using LET, run

tutor list

and you will get this output:

LET SKIP_EMAIL_VALIDATION = True

Do you want to see what can be done with LET? Just run tutor list --all to see all available settings and there modified or default values.

And to to get some inspiration, add --output table to get a nice table of all the available settings, together with their data type, default and set values.

tutor list --all --output table

The README file has a full list of all settings together with a small description. Check it out at the PyPI page or at Github!

Some notes

  • tutor list will not show all values, only those supported by LET
  • Not all values can be set with tutor let. Run tutor list -a to see which settings are available.
  • To finally apply the change you will have to, in most cases, restart the containers. In some cases you will have to rebuild the Docker images. In other, run a do init --limit let tutor command. It is generally documented in the README file.
  • Run tutor list -h to see all available listing options.

Contributing
Your contributions are welcome! Please feel free to open an issue in the project page to report any bug or improvement suggestion.
If you think that a new setting is worth including in LET, let us know!

Why LET?
Those who grew up programming BASIC in home computers must be familiar with the LET and the LIST commands. We are not bringing BASIC into Tutor… we just got inspired on those ages when life was easier and things were simpler!

14 Likes

Nice! Now we just need a UI for this :stuck_out_tongue:

3 Likes

By the way, I think there’s a lot of overlap here with OEP-68: Openfeature Toggles - once the changes proposed in that OEP are accepted, I think it would be much simpler and easier to implement this sort of plugin, since there’d be a unified API for all the config settings built in. Please comment on that PR if you have thoughts.

I have a more radical opinion about settings. I think that only a very few core settings, like the site URL or database connection data, should be configured in Django’s settings. All the rest should be moved to a model, stored in a db table and managed via web interface (whether Django admin or a dedicated MFE). I’m planning to write a product proposal for that.

1 Like