plugin: doesn't work well with modules, requires coordinating dependency versions #43749
Labels
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
Unfortunate
Milestone
Comments
|
This reads more like a question or a request for help than a bug report, since there isn't a way to reproduce the issue or any clear details pointing at a bug that can be fixed. Have you seen https://golang.org/wiki/Questions? |
mvdan
added
the
WaitingForInfo
|
Thanks @mvdan . For example, we have following project as the shared "library". go.sum It is very likely for some new plugin to use different packages from the above "go.sum". It will lead to the problem for example the main binary cannot load the plugin because of "different version of package" or different plugins cannot work together. The problem is not for one case that we cannot resolve with new revised configurations. The problem is that we may have to upgrade the main binary and all 100+ existing plugins to adapt to a new developed plugin. And according to the statement in Go 1.14 release notes at "https://golang.org/doc/go1.14", I need to open an issue: |
|
how is this better with |
|
@seankhliao We do need Golang to provide something like a lightweight Java OSGi does. |
|
So same root cause as #18827 but the desired result is in the opposite direction |
|
I think it is more of a request for supporting vendoring outside main module too. Currently, https://golang.org/ref/mod#vendoring
|
seankhliao
added
WaitingForInfo
|
Does building everything under a shared workspace help? |
|
We do not have shared build server with our partners. It is not feasible. |
seankhliao
removed
the
WaitingForInfo
seankhliao
changed the title
heschi
added
the
NeedsDecision
|
@seankhliao if you were asking about go workspaces, then no - plugins have a |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
We have an app using a lot of Golang plugins developed by many teams. It works very well with Golang Dep.(https://github.com/golang/dep) because you do not need to care any compatibility issues caused by the new packages of the plugins and all those in the vendor directory because they are all independent.
While when we migrate to Go Modules, there are various compatibility issues. For most scenarios, we need to refine the shared projects and then we have to change all plugins developed by many teams. The workload is huge.
Though finally, we can fix the problem with various ways, the cost is too big so that we have to go back to Golang Dep.
What did you expect to see?
Like with Golang Dep, if we can build the GoLang plugin successfully, then we can load the plugin with the main app and all plugins can work together without any issue.
What did you see instead?
Right now, when we successfully build a GoLang plugin, it does not mean the plugin can be loaded and it does not mean it can work with other plugins. There will be various "different version of package" issues.
The text was updated successfully, but these errors were encountered: