Task Organization Conventions

[bobeagan]

I wanted to propose a more rigid organization for tasks. I welcome any feedback on this. It is currently just a rough idea that I wanted to get written down and to open a dialog.

Right now, using migrations as an example, there is no formal structure and some tasks that don't make sense due to lacking context. For example db:status returns the status of migrations so db:migration:status would be a better name.

I think that the task calls should be fixed into exactly three parts: resource:group:task

Resources would be the target of action for the task, such as db or app. This would be a high level grouping. It may make it possible to provide a way to list available task groups for each resource by doing something like ./minion db or ./minion app which would search and list all of the groups from any modules and the application that belong to that resource.

Each resource could potentially have multiple task groupings (such as db:migration or db:backup). The main call to task grouping would trigger the default task. The task group would have to define what that task is but the task must exist to be called explicitly as well. For instance, if the default task for db:migration was :up, then db:migration and db:migration:up would function identically, similar to accessing a website with or without the index page specified. This will make for more clearly organized tasks and groupings. An alternative idea is to remove the optional default task and instead make calling db:migration search for and list all tasks belonging to that group similar to how the listing of groups for a resource is done.

To go along with this proposed change, it may make sense to refactor the class directory structure to remove "task". This would be a potential directory structure for the migration tasks module:

classes/
    minion/
        db/
            migration.php
            migration/
                up.php
                down.php
                status.php
                create.php

Looking forward to feedback on this.

[ThePixelDeveloper]

I agree with everything here.

I'd prefer to not have a default task though because db:migration is not descriptive. You have no idea what it could do from the terminal. There's an advantage to having it return a list of tasks too. Parse the output and use it for bash_completion

[BRMatt]

Sorry for not replying to this earlier, life has a habit of getting in the way of things.

Personally I think this would be better implemented as a convention or standard, rather than saying "this is the way you must work". Having "default" tasks is easily accomplished by extending tasks, e.g. Minion_Task_DB_Migrate extends Minion_Task_DB_Migrate_Status. I'd prefer to avoid forcing people into into only having 3 levels in case they need to be more (or less) granular.

The idea of passing part of a task name to get possible tasks is definitely a good one.

We'd probably need to provide a switch to force minion return a list of candidates (e.g. if they tried to list all tasks under db:migration and it ended up executing the task). Something like --list-tasks?

[bobeagan]

I really don't see a problem with enforcing some strict rules to avoid chaos. If there was expected functionality between all tasks. it would make it easier to script things knowing that certain actions will always produce the same type of results or act in the same manner.

[zeelot]

I don't like the idea of default tasks and can't see a need to list tasks in a group if you can just do ./minion to see all of them. For the naming conventions, I've just been putting the tasks under the name of the module, but I don't really see strict naming conventions helping much.