Incorporate plugins

[sdboyer]

plugins are here as of Go 1.8. Despite some of the general issues and difficulties with getting plugins to compile using objects shared with the main program, it seems likely that we'll need to do something with them as part of dependency management.

Problem is, I'm not sure much we could really do via static analysis to determine what plugins are necessary. The import names are just strings, and if the focal point during analysis is an individual file in a particular package (with a plugin.Open call site), then the origin of those strings could easily be in a package from an entirely separate project, or generated based on the input to a running program.

If we can't provide any assurances about the completeness of analysis, then it suggests dep should handle plugins - if it does at all - through an entirely different mechanism than typical import-based dependencies. Perhaps explicit declaration in the manifest? I don't know.

In any case, this issue is here for some open discussion on the topic.

[davecheney]

I'd save your innovation tokens and pass on plugins. With just over a month left in the 1.9 dev cycle it doesn't look like the plugin situation is going to improve for Go 1.9, and that isn't even considering that they're not enabled on mac and nobody has committed to supporting them on Windows yet.

…

On Thu, Mar 23, 2017 at 1:41 PM, sam boyer ***@***.***> wrote: plugins <https://golang.org/pkg/plugin/> are here as of Go 1.8. Despite some of the general issues and difficulties with getting plugins to compile using objects shared with the main program <https://groups.google.com/forum/#!topic/golang-nuts/IKh1BqrNoxI>, it seems likely that we'll need to do *something* with them as part of dependency management. Problem is, I'm not sure much we could really do via static analysis to determine what plugins are necessary. The import names are just strings, and if the focal point during analysis is an individual file in a particular package (with a plugin.Open call site), then the origin of those strings could easily be in a package from an entirely separate project, or generated based on the input to a running program. If we can't provide any assurances about the completeness of analysis, then it suggests dep should handle plugins - if it does at all - through an entirely different mechanism than typical import-based dependencies. Perhaps explicit declaration in the manifest? I don't know. In any case, this issue is here for some open discussion on the topic. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#347>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA89Z9_jdjNLEWP2e2-lq-St5fMHLks5rodvkgaJpZM4MmGAJ> .

[sdboyer]

@davecheney fully agree, this is not a priority. Really just opened it so that there's a place for any thoughts or ideas that might come up as we move along.