Hooks or meta commands

[nikolay]

I was under the impression that RUN.BEFORE and RUN.AFTER worked differently. In fact, I thought that I could do the following (especially valid when you have multiple Runfiles):

The contents of ./commands/homebrew/Runfile:

# RUN.AFTER upgrade
upgrade-homebrew:
  echo "Upgrading Homebrew"

The contents of ./commands/aqua/Runfile:

# RUN.AFTER upgrade
upgrade-aqua:
  echo "Upgrading aqua"

The contents of ./Runfile:

INCLUDE **/Runfile

upgrade:
  echo "Upgrading..."

So, I naively hoped that I could wire in more commands in various ./commands/*/Runfile files without having to wire them in ./Runfile, so, if I would get the following result in the setup above:

$ run upgrade
Upgrading...
Upgrading Homebrew
Upgrading aqua

It came out I was wrong and that RUN.BEFORE and RUN.AFTER are just syntax sugar for "${RUN}" <command>, which is not enormously useful.

So, I propose adding the HOOK.BEFORE and HOOK.AFTER, so that the above could work if I replace RUN.AFTER with HOOK.AFTER.

Another option is to make upgrade call other commands using a wildcard, i.e.

# RUN.AFTER upgrade-*
upgrade:
  echo "Upgrading"

[TekWizely]

Greetings!
So I'm not sure about adding some kind of glob matcher to run multiple tasks, but I did devise a way to achieve your goal:

Runfile

UPGRADE_CMDS = ""

INCLUDE **/Runfile

##
# export UPGRADE_CMDS
# export .RUN, .RUNFILE
upgrade:
  echo "Upgrading..."
  declare -p UPGRADE_CMDS
  for cmd in $UPGRADE_CMDS; do ${RUN} -r ${RUNFILE} ${cmd}; done

./commands/homebrew/Runfile

UPGRADE_CMDS="${UPGRADE_CMDS} upgrade-homebrew"

upgrade-homebrew:
  echo "Upgrading Homebrew"

./commands/aqua/Runfile

UPGRADE_CMDS = "${UPGRADE_CMDS} upgrade-aqua"

upgrade-aqua:
  echo "Upgrading aqua"

And when executed:

$ run upgrade

Upgrading...
declare -x UPGRADE_CMDS=" upgrade-aqua upgrade-homebrew"
Upgrading aqua
Upgrading Homebrew

Give that pattern a try and lemme know what you think, and as always, thanks for the discussion!

-TW

[nikolay]

@TekWizely I didn't know what happens with the variables declared in the Runfiles, so, thanks for this. The issue is that it looks somewhat clean if you have UPGRADE_CMDS, but, in my case, there will be LINT_CMDS, FORMAT_CMDS, VALIDATE_CMDS, and LOCK_CMDS (for updating lockfiles), etc. Thanks for the suggestion though!

[TekWizely]

So I'm starting to warm to the idea of supporting run prefix*

1. I think it would have to fail on the first failed task
2. Passing arguments would pass them to all tasks
3. Passing something like --help may have to stop after the first task

I will definitely grind on this some more

[nikolay]

@TekWizely Of course, all these should have identical signatures, i.e. they should support the same type of options, switches, etc.