[FEATURE REQUEST] adding custom plugins

[dstrop]

Is your feature request related to a problem? Please describe.

I would like to build the binary with custom plugins but since 2.0.4 the cli package was moved to internal and i can no longer add my plugin

Describe the solution you'd like

move cli package outside of internal

Describe alternatives you've considered

a) public interface in root package (roadrunner_binary) which would allow me to run cli.Container.Register and cli.Execute this would be nice and still allow you to controll what is exposed b) implement golang plugins https://golang.org/pkg/plugin/ this would be ideal solution as i would be concerned only with plugin interfaces, but might be hard to implement c) clone the roadrunner-binary project and maintain custom branch

Additional context

i am working off of https://roadrunner.dev/docs/beep-beep-build which suggests Copy main.go file in the root of your project

for a code on 2.0.2 but since cli is in internal this no longer works

package main

import (
    "log"

    "github.com/spf13/cobra"
    "github.com/spiral/roadrunner-binary/v2/cli"
)

func main() {
    cobra.OnInitialize(func() {
        err := cli.Container.Register(&myPlugin{})
        if err != nil {
            log.Fatal(err)
        }
    })

    cli.Execute()
}

this might be considered a bug or a regression since it was suggested by documentation

[rustatian]

Hey @dstrop . You can add your custom plugin to: https://github.com/spiral/roadrunner-binary/blob/master/internal/container/plugins.go. There is no difference where located plugin registration because you still need to fork/clone repository to add your custom plugin and then build the binary.

[dstrop]

i didnt need to fork the repository i just importedroadrunner-binary` as go mod dependency as you can see in the code snippet

but i take it as forking is the recomended way forward. thank you

[rustatian]

And the answers to your points:

1. Public interface for the CLI is the commands which the user allowed to run, such as: serve, workers, reset at the moment.
2. We are waiting for the native plugins support: https://github.com/spiral/roadrunner/issues/474, but at the moment, Windows is not supported, thus we can't move forward here w/o designing our own solution here (I'm slowly working on that).
3. Yes, this is something that expected to be with custom plugins. Unfortunately, there is no general solution (yet) to build SO/DLL's as the plugins and attach them dynamically in the runtime.

[rustatian]

i didnt need to fork the repository i just importedroadrunner-binary` as go mod dependency as you can see in the code snippet

but i take it as forking is the recomended way forward. thank you

Yes, the roadrunner-binary repository should not be imported as the library. Please, do the clone or fork.

[rustatian]

To create your custom solution, import (import "github.com/spiral/roadrunner/v2") the roadrunner main repo, which is designed as the library and supposed to be cloned/forked. Then add your CLI and custom plugin(s).

[rustatian]

Thanks for the FR @dstrop , I'm going to close this ticket and open a new one to update mentioned documentation page (https://roadrunner.dev/docs/beep-beep-build)