2025-08-02 MyCmd and MyProject Weekly Progress Report: 2025 Week 31

MyCmd and MyProject Weekly Progress Report: 2025 Week 31

Calling Tasks From Other Tasks

This week was a little bit of a struggle as I was trying to figure out some design decisions in MyProject. I was primarily working on the capability to call tasks from other tasks.

As a reminder, in MyProject, projects tasks are defined in one or more task definition files in a myproject task definition directory – for example this is MyProject’s own task definition directory.

When executing tasks with mycmd myproject run, tasks that are defined in the main task definition file, you simply use the task name that is registered with the call to myproject.register_task. To execute tasks defined in any other task definition file, you specify the task by the file name and the task name, like test execute-all to execute task execute-all in the test file.

Because of this, to avoid ambiguity, I have made it so you cannot declare a task with the same name as another file. For example, if you have a task definition file named sub, you cannot register a task in main named sub.

However, I have now added the functionality for tasks to call other tasks, via myproject.execute_task and myproject.execute_tasks. As a convenience, you can call other tasks defined in the same file by just using their task name, without having to specify the filename. Because of this, there is a potential for ambiguity. Users could define tasks with the same name in the main file and other tasks files. So, my work this week was to report these ambiguities.

But I ran into issues when writing tests for this. The code was throwing errors when it shouldn’t have. I felt stuck.

Simplify, Simplify, Simplify

I ended up taking a couple day break from MyProject, but was pondering how to handle the bit of challenge I was in. But, this morning while writing my Morning Pages, I had a realization. The complication in my code was because I had implemented lazy loading for task files. When mycmd myproject run is called, only the main file is loaded until a task from another file was referenced. But this lazy loading was causing issues when trying to see if a task name referenced in an execute task call existed.

But then I honestly realized that I didn’t need lazy loading. Loading a large task definition directory is fast. The design decision to split up MyProject task definitions into multiple files was not to optimize evaluation time. It was to help with the cognitive overhead of having all of the task things in one single file. The myproject tasks file in the old format is the largest source file in the MyProject by over two times. So to make it easier for task definition file writers and for the namespacing of task names, I split things up into separate files. But lazy loading wasn’t a necessary contributor to those benefits.

With that realization, I pushed this commit that removed over 200 lines in implementation and test code. Things are simpler. And my previous ambiguity reporting code is now working as expected.

The lessons?

Demo

This week’s demo is demonstrating the reporting of an ambiguous myproject.execute_task call, in this case sub task3 from one of the projects in MyProject test data. This task is trying to execute task2. This is ambiguous because there is a task2 defined both in the sub file and in the main file.

mycmd myproject run sub task2

MyProject Updates

This week I pushed 7 commits to MyProject this week, including the following:

Next Week

This took a little longer than I would have liked. I will be able to spent time next week to add convenience methods for verbosity output control. And then possibly starting to port MyProject files for my other projects to task definition directories.

All of my MyCmd and MyProject Weekly Progress reports will be linked from here.