@ianlancetaylor is there any chance to add this issue to the 1.8.1 milestone as it makes the usage of vendoring nearly impossible in the context of plugins?

Adding the 1.8.1 milestone to this issue won't fix the problem. When and if we have a fix on tip, then if the fix is simple and safe, we can consider adding it to 1.8.1.

As mentioned in #19233, this sounds like the behavior described at #12432. Unless this behavior is set to change in 1.9, this seems like a non-issue, albeit annoying in the context of plugins.

@edaniels it really seems like the behavior you mentioned but the nuance resides in the fact that this issue happens on run time. I understand that this is the "plugin" version of the behavior, but this is also far more annoying for end users as it can't be detected at compile time.
Plugins come with a lot of advantages but also open the pandora's box. IMHO, the main advantage is to allow the separation between a core program and a myriad of run time functionalities developed by different folks but this kind of issues constraint both parties to know about each others and conform to a set of common dependencies rules.
Maybe we should come up with a freshen look about vendoring in the context of plugins.

I totally agree. It's probably a discussion for another issue but it seems like this is an issue for vendoring in general and maybe the go tool chain should be more aware of package identity in the future. To make plugins more useful something will need to be done.

If you built this as a single program, there would be two separate packages for foo. There would be two instances of any global variables, and the types you are comparing would be different.

It seems very strange to me that plugins would de-duplicate vendored packages. What if a plugin has vendored a different version of a package because it wants to use a different version? The only thing we could do in plugin.Open is fail in this case, because the packages wouldn't be compatible.

It would also be impossible to build a plugin that vendors two different versions of a package under different subtrees. I can't say I've ever done this, but all of this is possible with the vendor directory in usual programs, so I think it should work in plugins also.

Sorry that we didn't look at this issue in the Go1.10 cycle, but I think we might have to move this to Go1.11. What do you think @crawshaw?

@crawshaw is on leave, so that's a yes: moving to Go 1.11.

Oh, right, I had forgotten. Thanks @bradfitz.

As this issue has been assigned to a milestone, what exactly is proposed to be changed/addressed?

@crawshaw says:

It would also be impossible to build a plugin that vendors two different versions of a package under different subtrees.

If this is the case, I'm struggling to find the relevance in the Plugin package entirely. If plugins are to always be tightly coupled with the dependencies of the project that loads it, why would I not just include that code in the parent project's source.

I am not sure if this behaviour is a bug or a feature. On one hand it prevents a base application and a plugin from passing shared types to each other, but on the other hand it allows two plugins to vendor different versions of the same dependency and still be loaded. Without this behaviour, the plugin loader will complain that the second plugin was built with a different version of the shared dependency.

The issue with a shared type being returned by a plugin function to the base could be worked around by either pulling that specific dependency out of vendor/ into the GOPATH or by using a combination of interfaces, type assertion and reflection to convert the two types.

Also should the discussion on this issue happen here or in #20481?

I tried using plugins a while ago and gave up. I had 2+ plugins (and the main application too) that use kubernetes libraries and kubernetes uses glog. So, 2+ glog copies, each trying to add a flag to the flag package. A flag cannot be added more than once -> glog/stdlib panics. Plugins are completely unuseable in such situation.
I think shared mutable state should be removed from standard library in Go 2.

A similar thing happens for plugins that import x/net/trace which in its init() adds some http handlers to the http.DefaultServeMux. So if you load 2 plugins that have vendored x/net/trace, the init() will panic because it gets executed twice and you can't have two handlers registered at the same route.

The only way to "resolve" this right now seems to be to reassign http.DefaultServeMux before loading each plugin.

Are there any updates on this? I agree with the commenters above that this renders plugins useless for a lot of use cases. There should at least be a warning at the top of the documentation of the plugins package that when working with vendored code you cannot share types between different packages.

Is there any progress? It's still very difficult to use plugins

It seems like plugins are effectively dead, support wise. They've received little mention since their release.

then are there any other alternative we can leverage?

Is there anything to do here?
With modules, all dependencies have a singular identity, and workspaces makes it relatively easy to keep dependency versions in sync across modules

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

This is not resolved, it's still a problem. Effectively Go can't be used to build something similar to Wordpress which loads plugins from a marketplace, even though it would be amazing

@Fire-Dragon-DoL Responding in a closed issue might not help and this topic should only be revisited when there are new ideas or information.
Anyway, you can build plugins, but not via the standard library. Like in many languages this use case is something the community should resolve and many larger projects did so. The best example is Traefik that leverages Yaegi, one of the most advanced Go interpreters, that was also built by the Traefik team. Traefik‘s plugin system uses Yaegi to execute code on the fly rather than trying to rely on pre-compiled and linked plugins that were built with Go‘s plugin package. This is a perfect and elegant solution with full flexibility and does not require official SDK support at all. The Traefik GitHub organization has many “official“ plugins as well as demo plugins like traefik/pluginproviderdemo and traefik/plugindemo which you can use to get an idea and some inspiration how it works. Also check out Yaegi before to roughly understand how plugins work under-the-hood.

@Fire-Dragon-DoL Responding in a closed issue might not help and this topic should only be revisited when there are new ideas or information.
Anyway, you can build plugins, but not via the standard library. Like in many languages this use case is something the community should resolve and many larger projects did so. The best example is Traefik that leverages Yaegi, one of the most advanced Go interpreters, that was also built by the Traefik team. Traefik‘s plugin system uses Yaegi to execute code on the fly rather than trying to rely on pre-compiled and linked plugins that were built with Go‘s plugin package. This is a perfect and elegant solution with full flexibility and does not require official SDK support at all. The Traefik GitHub organization has many “official“ plugins as well as demo plugins like traefik/pluginproviderdemo and traefik/plugindemo which you can use to get an idea and some inspiration how it works. Also check out Yaegi before to roughly understand how plugins work under-the-hood.

Thank you, I was not aware of Yaegi, it can definitely help the problem!

It seems like there is still a big performance penalty, sadly, but there might be no other solutions.

Edit: there seems to be some serious limitations to yaegi to importable packages unfortunately.

@Fire-Dragon-DoL have you looked into using WASM?

It seems like at this point the feature may as well be removed to avoid confusion.