Development Notes

Module and Script Layout

Since the moodle-tools scripts have dashes in their names, the following conventions should be followed so that unit tests can be easily written:

src/mdl-script <- the main script
src/MoodleTools/mdl_script.py <- application class (contains "main" method)
src/MoodleTools/OtherClass.py <- module used by the script
src/MoodleTools/AnotherOtherClass.py <- another module used by the script

This allows a class/functions that would normally be included directly in src/mdl-script (but could not be tested due to not being able to from mdl-script import * due to a dash in the name) to be contained in another file that is easily identified as being associated with that specific script. See src/mdl-server and src/MoodleTools/mdl_server for specific examples, and see test/test_mdl_server for examples of testing a module like this.

Calling moodle-tools Programs

I kind of like the git style of calling programs. For example, instead of using mdl-server param param2, we could use mdl server param param2. From the Git source:

while (*argc > 0) {
	const char *cmd = (*argv)[0];
	if (cmd[0] != '-')
		break;

	/*
	 * For legacy reasons, the "version" and "help"
	 * commands can be written with "--" prepended
	 * to make them look like flags.
	 */
	if (!strcmp(cmd, "--help") || !strcmp(cmd, "--version"))
		break;

Locating moodle-tools

The --exec-path parameter Git uses is a good idea, including an environment variable. This would make testing easier.

—exec-path
Path to wherever your core git programs are installed. This can also be controlled by setting the GIT_EXEC_PATH environment variable. If no path is given, git will print the current setting and then exit.

if (!prefixcmp(cmd, "--exec-path")) {
	cmd += 11;
	if (*cmd == '=')
		git_set_argv_exec_path(cmd + 1);
	else {
		puts(git_exec_path());
		exit(0);
	}
}