It really depends on what you want to achieve... 1. dynamically discovering *out-of-process* RPC plugins ... Hashicorp's might be the most famous one. 2. dynamically discovering and loading *shared lib *plugins ... this needs some plumbing above the pure stdlib plugin functionality. Personally, I find the shared libs to be finicky and haven't yet done a real project that needed this variant (but I wrote a go-plugger <https://github.com/thediveo/go-plugger> module as an example). 3. statically binary-builtin plugins: this actually is what I tend to use in several of my own projects, where there is no need for dynamically extending but instead to easily maintain and use a fixed set of "plugins" and that set of plugins tends to slowly grow. The plugin mechanism might help organizing, such as my own go-plugger <https://github.com/thediveo/go-plugger> supporting type-safe plugin APIs and ordering and iterating plugins at runtime. For instance, I use this mechanism to simplify adding new types to factories, or to "decorate" containers with additional labels, such as in Docker compose contexts, or k8s contexts, or ...
On Wednesday, August 2, 2023 at 12:14:15 PM UTC+2 alex-coder wrote: > Hi All ! > Plug-in package is very interesting, but in case the development under > windows it does not work, > So, any hint to use some option instead will be highly appreciated. > > Thank you. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/01ffc6c2-962d-497d-abad-5940ff11da48n%40googlegroups.com.
