This ticket is about our dynamic action plugin. A fine feature that is just missing a bit of polish before our users can profit from it.

I'll split the issues into two categories. Issues blocking the release of this feature and nice to haves that would be great to have but aren't necessary for v1.

Blockers

• The current API is monadic. This imposes serious limitations on users that might be working with their own monad already (lwt, fiber, memo). The obvious solution is to introduce a transformer.

Non-blockers

• The dynamic-run constructor in the action language. IMO this extra bit information is something that breaks abstraction. Users shouldn't worry about the details of how a binary is interacting with the build system. We should allow custom rules, preprocessing rules, builtin rules to use the action API without any additional annotations in build files.

• Currently, >>= in the action plugin is needlessly slow. It could be made much faster if action plugins were rpc clients.

• There's a lot of duplication between the versioning story of dune's rpc protocol and the dap protocol. We should use the same API and versioning concepts for both.

The last 3 points can all be addressed at once by re-implementing dap with dune rpc. The only downside is that now we'll need dune to run the rpc server outside of watch mode as well. I don't see how this would cause issues though. If there's agreement on this point, I can describe the design in a little more detail.

cc @snowleopard @Alizter @tmattio