Moving from Phing to Robo, an evaluation

[grasmash]

I'm the maintainer of https://github.com/acquia/blt, which relies heavily on Phing for task running operations. I'm considering a gradual move to Robo. I've put a bit of work into a pull request that attempts to do a line-by-line conversion of a Phing file into a Robo file.

I'd like to share my thoughts and ask a few questions before going further.

1. Is there a mechanism in Robo for defining a custom logger that would permit customization of the output format for core tasks?
2. Most task runners incorporate the concept of a "build properties" file, which allows a set of key value pairs to be defined in a file and passed to the task runner at run time. One particularly useful feature of Ant and Phing is that they permit property expansion in such files, see build.yml for example. Additionally, there is a convention for overriding such properties via CLI arguments. E.g., robo -Dkey=value. Is there any precedent for using such a file with Robo?
3. Is there a mechanism for defining application level options to robo commands? E.g., If I'd like every command to accept a -v, -vv, or -vvv option to set the verbosity level, is this possible?
4. Is it possible to override a default task defined by Robo?
5. Some task runners incorporate the concept of filesets and patternsets. Essentially, this allows a set of files to be selected and then filtered by some regex. Those files can then be operated upon by a task. Does this concept exist in Robo?
6. It is common for task runners to allow one task to "depend" on one or more others, permitting tasks to be chained together. It seems like a "@Depends" tag in the annotated command could serve this purpose. Would there be any interest in adding this?
7. As a general question, what is the status of this project? Are the maintainers actively interested in developing new features? Is there a roadmap established?

Thanks for your time. Please let me know if I've overlooked anything, or if there is interest in adding any of these features. I'd be open to submitting PRs to that effect.

[greg-1-anderson]

Answered these in chat a couple of weeks back. Some answers for posterity:

1. Yes, but only if you build your own application. See robo as a framework, which shows how to define a dependency injection container and modify it.
2. Discussing in Add concept of build properties to Robo #516
3. Global options may only be added if you build your own application. Some folks use @hook options to define common options for multiple commands; it would probably be better if there was another annotation specifically for this purpose, so that it was not necessary to define a hook with an empty function definition if you only wanted to add options.
4. I've never needed to do this, so I haven't tried. It is possible to override methods of traits in a class, so it would probably work to override taskFoo() in your RoboFile.
5. The Robo way to do this is to use Symfony Finder or some other file collector, and then pass the files found into the appropriate setter methods of your tasks. Also, I have been intending to implement "pipelines" for Robo, to allow one task to pass a collection of files (or whatnot) to the next task in the pipeline, if desired. This effort has not been started.
6. c.f. Fixes #65: Allow commands to call other commands annotated-command#65
7. Robo was in very active development for the push to 1.0. The maintainers remain interested in improving this project, although there is no formal roadmap for future versions at this time.