Why Modulestore?

• Technically, a low-level library with little to no dependencies on the rest of the platform.
• Does not change very often - and especially not that often by the new TNL team.
• It's one of the common dependencies between LMS and CMS.  So extracting the MS would pave the path toward splitting them as well.
• MS tests take about 8mns on Jenkins - that amount of test time would be shaved off of edx-platform builds.

Hackathon Experiments

As part of edX Hackathon XV, I experimented extracting out the modulestore code and its dependencies out into separate repos.  I ended up creating the following 2 repos:

• edx-platform Modulestore: https://github.com/nasthagiri/modulestore
• edx-platform Core: https://github.com/nasthagiri/edxcore

In so doing, there were a few dependencies that needed to be judged on whether they should (1) be refactored so they can be extracted out with the modulestore code or (2) remain within the edx-platform.  For example, I made the following decisions:

• The definition of DEFAULT_START_DATE was moved into inheritance.py and moved with the modulestore code.
• The course_metadata_utils.py module and its helper functions remained in edx-platform.

Since the work was done as part of a hackathon and within 2 hours, mostly for experimentation, accurate documentation wasn't kept.

Guidelines for Future Attempt

When this work is re-attempted, we should make sure to keep a clean git history, by doing the following:

1. Initial commit should be just the base django cookie-cutter created files.
2. Second commit should be just the unmodified copy of the modulestore code from the edx-platform (so all subsequent changes can be reviewed).
3. Then, the following commits should be separated:
   1. All Python-3 compatible edits.
   2. All missing dependencies added to the requirements.
   3. All quality fixes.
4. All other functional modifications should be kept as subsequent separated commits so they are easier to review and track.