Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: Allow building non-main package with -buildmode=plugin #18124

Open
captncraig opened this issue Nov 30, 2016 · 8 comments
Open

cmd/go: Allow building non-main package with -buildmode=plugin #18124

captncraig opened this issue Nov 30, 2016 · 8 comments
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@captncraig
Copy link

The plugin package currently requires a main package as an entry point to use -buildmode=plugin. I would like to use the plugin package to load library packages at runtime, which are only used for their initializers. Plugins usually look like:

package myPlugin

import "github.com/someApp/plugins"

func init(){
  plugins.Register(myThing)
}

The current methodology is that these are compiled into the host with import _ "myPlugin" In order to support loading at runtime as well, each plugin needs a second main package that is literally:

package main

import _ "myPlugin"

func main(){}

This feels like unnecessary boilerplate. At Ian's suggestion I propose modifying the go tool to generate such a main package when using -buildmode=plugin and a single non-main package is built.

I plan on working on this feature.

@captncraig
Copy link
Author

Turns out this is not so easy. This solution would solve my immediate use case, but only because my plugins do not need to export anything. The generated main package hides the exports from the actual package you want to build, and the host app won't be able to find them with Lookup.

The only solution I can think of is essentially rewriting all go files in the package to a tmp directory and rewriting the import to main. Probably out of scope of what you would be willing to accept for this.

Any other ideas?

@ianlancetaylor
Copy link
Contributor

I see, you're right, I was thinking more of c-shared and c-archive, where any package can export a symbol (by using a magic cgo //export comment). For plugins I think you really do have to write a main package, except, of course, for your use case which I think is too uncommon to treat specially.

@captncraig
Copy link
Author

Does it not seem a bit silly needing to write a main function that never gets executed though?

@quentinmit quentinmit added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Dec 6, 2016
@quentinmit quentinmit added this to the Go1.9Maybe milestone Dec 6, 2016
@bradfitz bradfitz modified the milestones: Go1.9Maybe, Go1.10 Jun 7, 2017
@Kubuxu
Copy link

Kubuxu commented Jul 13, 2017

I also just hit this issue, as we want to support either dynamic loading of plugins or preloading them during build of the program, I will be generating mainpackage for all plugins during build process.

This will only work for us as we use single variable export as entry point of plugins.

@rsc rsc modified the milestones: Go1.10, Go1.11 Dec 1, 2017
@gopherbot gopherbot modified the milestones: Go1.11, Unplanned May 23, 2018
@septatrix
Copy link

Is it not possible to treat the package as if it were the main package? It is already possible to build a plugin from a package without a main() function

@titpetric
Copy link

go.work in particular is problematic - if you share /a and /b in a workspace, the plugin under /b will error out with -buildmode-plugin requires exactly one main package. The error is logical, however, I'm struggling to build a plugin from /b that has a dependency in /a, and aside from moving it from /b into /a, I had zero success.

@QuinnCiccoretti
Copy link

@titpetric Any updates? I am in a similar situation with go workspaces and I am getting the same error. Thanks.

@titpetric
Copy link

@titpetric Any updates? I am in a similar situation with go workspaces and I am getting the same error. Thanks.

I'd suggest reading the plugin godoc, and avoid 'plugin' as the name for the plugin. Plugins do compile in a workspace.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests

10 participants