sedrila 1.1.0

Tool infrastructure for building and running "self-driven lab" courses

sedrila: Tool infrastructure for building and running "self-driven lab" courses

A "self-driven lab" (SeDriLa) course is one where students select freely a subset from a large set of tasks. The tasks are described with sufficient detail that no guidance from an instructor is needed most of the time.

sedrila is a command-line tool supporting course authors for authoring a course and then course instructors and students for executing it.

Find the documentation at readthedocs.

Ideas for future versions

• Process SEDRILA_INSTRUCTOR_COURSE_URLS as described in the instructor documentation.
• sedrila instructor should keep a JSON file student_course_urls.json that maps student usernames to the course URL first seen for that student, because if a student ever changed the URL in the student.yaml, prior signed commits of instructors might become invalid semantically if the new course has a different set of tasks.
  The map is added to when a student.yaml is first seen and checked against at each later time.
  Note that a student taking part a second time, with a fresh repo, might require manual editing of that JSON file to remove that entry.
• Better yet, there could be an option sedrial instructor --allow-repo2 that performs that editing automatically and also checks that the new repo contains no instructor-signed commits.
• Command sedrila instructor --clean-up-repos-home to clean up instructor work directory trees-of-trees by deleting all level-1 subtrees in which the student.yaml has a course_url that is not mentioned in the SEDRILA_INSTRUCTOR_COURSE_URLSenvironment variable. This option should ask a safety question before starting to work.

Development process: TODO-handling during development

We use this convention for the development of sedrila. It may also be helpful for course authors if the team is small enough.

If something is incomplete, add a TODO marker with a priorization digit:

• TODO 1: to be completed soon (within a few days)
• TODO 2: to be completed once the prio 1 things are done (within days or a few weeks)
• TODO 3: to be completed at some later time (usually several weeks or more into the future, because it is big) or never (because it is not-so-important: "nice-to-have features")

Add a short description of what needs to be done. Examples:

• TODO 1: find proper formulation
• TODO 2: restructure to use ACME lib
• TODO 3: add automatic grammar correction

If you intend to do it yourself, add your name in parens:
TODO 1: find proper formulation (Lutz)

Then use the IDE global search to work through these layer-by-layer. Demote items to a lower priority when they become stale or remove them. Kick out prio 3 items when they become unlikely.

A currently needed refactoring: Target directory structure

The current layout of the source tree is wrong. Currently, the templates and baseresources directories will end up as top-level directories when the package is installed, which means they will clash with any top-level modules of that name anywhere in our dependencies.

We need to perform the following refactorings to arrive at a proper structure:

• py --> sedrila: This will be the top level directory that gets installed.
• sedrila/sdrl/* --> sedrila/*: We remove the now-intermediate namespace. This implies joining the current sdrl/tests into sedrila/tests.
• templates --> sedrila/templates: The HTML templates simply become part of the tree to be installed.
• baseresources --> sedrila/baseresources: Ditto.

These changes require a lot of changes of import statements. For instance, the current module base will become sedrila.base and sdrl.course will become sedrila.course. The logic for computing sedrila_libdir in courses.py must be adapted. The files lists in pyproject.toml must be corrected.