You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apparently, in order to use Go plugins, you have to ensure that both the main binary as well as the plugin binary have been built with the same value of GOMODCACHE (which defaults to $GOPATH/pkg/mod). See golang/go#63230. (Exception: If you use -trimpath as build option for building both binaries. But I assume this is not an option for krakend, as all current plugins would break if krakend introduced that parameter in their build chain).
This was a bit surprising to me, as the error message is also not very helpful (plugin was built with a different version of package golang.org/x/xerrors/internal or similar, since Go apparently considers the two plugin versions to be different because of a different file path ).
The value of GOMODCACHE should always be /go/pkg/mod (default is GOMODCACHE=$GOPATH/pkg/mod)
You usually only have to set this value manually if you use a different GOPATH than the default path /go
Tip: You can check go environment variables with go env GOMODCACHE or just go env (list all), since they are not necessarily set in the system's environment variables
Side note: Maybe it would make sense renaming that documentation page to "Building custom plugins"? Since it's more about the build setup and commands, and less about writing the actual code. I found that heading a bit misleading.
The text was updated successfully, but these errors were encountered:
Renaming the heading to "building plugins" is a good suggestion. This page was originally about writing plugins, but it was split into multiple pages, and the title stayed.
About the GOMODCACHE value, you are right, and because Go plugins are complex we offer a builder image, so developers do not need to care about this. If you faced this is because you are compiling plugins without any of the builders.
I think that adding this details, while we try that users use the builder, is adding unnecessary information.
Hi @alombarte, actually I was using the builder image, but I added the GOMODCACHE environment variable to speed up the build process. As I'm new to plugin development in Go, I was unaware that this caused the Go plugin to be unusable and it took me some time to identify GOMODCACHE as the cause of failure. Using the builder image actually removes the need for deep knowledge of Go plugins, so I think having a note on this environment variable would indeed be very helpful, especially for builder users.
Apparently, in order to use Go plugins, you have to ensure that both the main binary as well as the plugin binary have been built with the same value of
GOMODCACHE
(which defaults to$GOPATH/pkg/mod
). See golang/go#63230. (Exception: If you use-trimpath
as build option for building both binaries. But I assume this is not an option for krakend, as all current plugins would break if krakend introduced that parameter in their build chain).This was a bit surprising to me, as the error message is also not very helpful (
plugin was built with a different version of package golang.org/x/xerrors/internal
or similar, since Go apparently considers the two plugin versions to be different because of a different file path ).So it might be helpful to document the required values in https://www.krakend.io/docs/extending/writing-plugins/:
GOMODCACHE
should always be/go/pkg/mod
(default isGOMODCACHE=$GOPATH/pkg/mod
)GOPATH
than the default path/go
go env GOMODCACHE
or justgo env
(list all), since they are not necessarily set in the system's environment variablesSide note: Maybe it would make sense renaming that documentation page to "Building custom plugins"? Since it's more about the build setup and commands, and less about writing the actual code. I found that heading a bit misleading.
The text was updated successfully, but these errors were encountered: