As a course convenor, you probably don’t need to worry about this stuff. But if you’re itching to customise things to work just the way you want them for your course then here are some tips which will help you out.

If the change is specific to your course, it probably belongs in a plugin in your course’s plugins/ directory rather than in lucy itself.

Layout#

  • code goes in lucy/; lucy.py is the click entry point, and the commands themselves are in lucy/commands.py
  • data goes in data/ (and should be committed to the repo); the JSON schemas everything is validated against are in data/schemas/, and the templates for course_info.yml, secrets.yml and the marking files are in data/templates/
  • course-specific commands go in plugins/
  • downloaded submissions end up in submissions/
  • marks end up in marks/, and reports in reports/
  • tests go in lucy/tests/

lucy.py loads and validates the course config (cfg.initialise()) before it imports anything else, so lucy has to be run from the top of a course directory, and the import order in that file matters.

Tests#

The tests come in three tiers: unit tests, tests against a dockerised GitLab that can backdate push events (so this is where deadline and extension logic is tested), and live smoke tests against gitlab.comp. Only the unit tests run by default:

PYTHONPATH=. poetry run pytest

See lucy/tests/README.md for how to run the other tiers, and how to write a test against the dockerised GitLab.

Formatting#

lucy uses Black, and CI fails if lucy/ isn’t formatted with it, so set it up on your machine (or run poetry run black lucy/ before you commit).

bars search times