MyCmd and MyProject Weekly Progress Report: 2025 Week 30

Demo

My demoable goal for the week was to be able to execute MyProject’s own project tasks with itself, which required 1) implementing a few new features, and 2) porting the single task definition file using the APIs of the old version to a task definition directory using the new APIs. And with these changes, I can now run MyProject’s project tasks with itself:

And here is the output of running mycmd myproject list-tasks for MyProject itself:

Porting to a Task Definition Directory

This work required changing the large single task definition file to a task definition directory. With this porting work, I updated some of the task names to use the naming hierarchy afforded by the multiple task definition files.

The following table lists the differences between the old and new tasks:

A few notes:

• I still have to figure out how I want to share code between projects. In the old version, this was done via project support libraries. I may still do this with this version.
• To get around this, I copied the two functions from project-shell-lib in the implementation in MyCmd core right into main for now.
• However, I haven’t yet copied over project-git-lib, and so the tasks in myproject/repo currently will not work.
• I still have to implement functionality around verbose and quiet output and so those changes will need to be made as well.

MyProject Updates

This week I pushed 11 commits to MyProject, including the following changes:

• Adding myproject.for_each_in_fileset and myproject.list_files.
• Implemented find_and_add_files that allows using GNU find to add files to a fileset.
• Separating out task execution functions into a new support library, myproject-execution-lib.
• Refactored project.execute_task to handle task resolution in a new function, and providing a new internal object, the execution task.
• Implemented project.execute_tasks to handle executing multiple tasks. Tasks are specified using their namespaced name (for tasks defined outside of the main task definition file, that is the file name and then the task name, so sub task1). Tasks are separated by an escaped semicolon (\;) in the call to project.execute_tasks.
• Exposed task execution to task definition files via myproject.execute_task and myproject.execute_tasks.
• Ported my existing task definition file for MyProject itself from the single file used with the old implementation into a new task definition directory.

I was pretty happy that I was able to stick with my goal of doing, on average, two hours of work each work day this week on MyProject and with the amount of progress I’ve made.

Next Week

I’ve also spent some time this week writing about how to handle ambiguity in resolution and execution of tasks – for example, what if a task in main and one of the other task definition files has the same name? I have some ideas on what to do there. I will pick up with getting those things documented properly and implemented next week. I need to expand my testing a bit to make sure I fully cover the new code I’ve implemented this week in automated tests. And then I need to add functionality for handling verbosity and other output controls.

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