Feature request: Pick up project-local robo version

[fago]

It would be great if a globally installed robo, would pick up any robo installed in a local project (via composer). That way one can add robo to the project dependencies in order to ensure that the robo tasks are always executed with the right version - but still conveniently run it via the global robo command.

[greg-1-anderson]

Like site-local Drush! 😄

We could certainly consider doing this, but redispatch code is more complicated than it first appears. I am working on factoring features out of Drush, and placing them in decoupled libraries in the Consolidation org. One of those projects might be helpful here eventually, or perhaps we could just try doing something simple natively in Robo.

In the meantime, though, I would suggest doing what I do: put ./vendor/bin at the head of your $PATH. This ensures that any binaries that are part of the project at your cwd will take precedence over anything in your global bin directories.

[fago]

yeah, like drush ;) - or other tools like grunt.
Meanwhile the PATH suggestion is a good workaround, thanks.

[fago]

A bit off-topic, but still: Another great feature of drush or tools like vagrant is the possibility to run it in any sub-dir of the project - I've been missing that in the composer world. Do you have some work-a-round for that also? I've been toying with the idea of writing some bash wrapper to find a composer.json and run various commands there via "composer exec foo".

[greg-1-anderson]

I don't remember if I've already pointed out the standalone robo scripts feature to you. If you have robo and your standalone script in your $PATH, then you can run it from anywhere. This also includes using the project-local robo with ./vendor/bin in your $PATH.

Note also that Robo already supports a --load-from (or -f) option that can be used to specify a particular RoboFile to use. So, you could make an alias similar to alias mytool='robo --load-from=/path/to/RoboFile.php'. This would be operationally very similar to a stand-alone Robo script.

I have also considered proposing multiple RoboFile support, which would allow us to support global commands, Drush-style policy files, and so on. However, the thing about this is that Robo has traditionally been a lightweight tool that works with a single RoboFile at once -- so robo help always shows you just your current set of commands. Adding multiple search locations might complicate Robo's primary use-case. @DavertMik is the final arbitrator of what Robo's vision and future direction in this area will be.

In the meantime, though, it would be trivial to make a new program that just extended the Robo Runner class, and used CommandFileDiscovery from annotated-command to invent your own rules for global commandfile searching.

Finally, you may already be familiar with drush-ops/drush#2103. Drush 9 will be based on Symfony/Console and the Robo task runner. With this PR, Drush commands === Robo commands; Drush will continue to use its existing commandfile discovery algorithms (with slight modification to account for the fact that commandfiles are now php class files).

[greg-1-anderson]

See also frameworks.md.