For the record, the CI failure is due to #568.

👍

For the record, in the two months since I proposed this PR (or the four months since it was put together for #458), I've decided to create a new project (https://github.com/plushu/plushu) rather than continuing to try to push a complete overhaul of everything through Dokku.

One thing I've noticed, as I've been referring back to this branch's code as reference for Dokku, is that, if this were to be merged, the config plugin would need to be fixed first (it currently uses a lot of variable definitions that just won't be there). Just for the record, I never tested this.

@josegonzalez for whatever reason this seems cleaner I like the idea of moving commands into plugins but I'm not completely sold on the premise to restructure subcommands. Thoughts?

For what it's worth, this subcommand structure is how Plushu has been working since the beginning, and it's worked just fine over the course of six months and ~50 plugins (in which it has reached and surpassed feature parity with Dokku).

@stuartpb the intention of my comment was not meant to judge the functionality of this structure. Instead, I'd like to understand the reasoning behind it.

dokku currently has all commands tucked away in a single commands file per plugin. To me that seems, very neat, concise, and makes it dead simple to execute against.

i.e.

for script in $PLUGIN_PATH/*/commands; do
  set +e; $script "$@" ; exit_code=$? ; set -e
  if [ "$exit_code" -eq "$DOKKU_NOT_IMPLEMENTED_EXIT" ]; then
    continue
  fi

  implemented=1
  if [ "$exit_code" -ne "$DOKKU_VALID_EXIT" ]; then
    exit $exit_code
  fi
done

Rather than

if [ -z $DOKKU_NO_COMMAND ]; then
  if [ -x $PLUGIN_PATH/$1/command ]; then
    "$PLUGIN_PATH/$1/command" "$@"
  elif [ -x $PLUGIN_PATH/${1%%:*}/subcommands/${1#*:} ]; then
    "$PLUGIN_PATH/${1%%:*}/subcommands/${1#*:}" "$@"
  fi
fi

Since I lack the understanding of the additional benefits, its seems to just be personal preference and the former is easier to understand for me than the latter.

Can you clarify why the subcommand pattern (i.e. $PLUGIN_PATH/*/subcommands/$command) is versus the current commands file pattern?

The big win that I've seen in Plushu is that there's way less non-deterministic boilerplate in each plugin. On top of making it way easier to spin up new plugins, when you don't have every plugin sticking its thumbs in the command parser, there's way less opportunity for a bug in a one-off plugin to break every other plugin in the system.

Can you give an example?

An example of one plugin needlessly breaking command handling for every other plugin? Say plugins/a-lousy-plugin/commands has a bug that causes it to sporadically exit early, with a status code that is not $DOKKU_NOT_IMPLEMENTED_EXIT. Every time that happens, the commands for every other plugin (whose name starts with something alphabetically lower than a) are skipped.

Or, say that its name starts with w, and it makes this error every time. Now, plugins with names that sort alphabetically lower than w (anything starting with x, y, or z) will never be reached - but you never realize it during normal operation, until the day you install a plugin like zero-conf, and assume that it's the new plugin that's faulty.

Ah that completely makes sense and this implementation bypasses that because you are executing the plugin command directly instead of iterating and executing every plugin's commands file every time you attempt to run any command. Got it. Thanks!

@michaelshobbs thoughts on this PR, or ideas we can/should pull from it?

Yeah I think we can/should use this pattern. I can take a swing at it. Let's leave this open for now.

Closing as #1039 is open. Thanks for your initial work @stuartpb !