Dep: 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 [e-mail] 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
https://github.com/golang/dep/issues/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.