Stop shipping imports/plugin.go for debuggability by default

[complyue]

Due to golang/go#23733 for Go 1.10~1.11, delve is unable to debug a Go app if "plugin" is imported, err like:

API server listening at: 127.0.0.1:64634
could not launch process: decoding dwarf section info at offset 0x0: too short

Debugger finished with exit code 1

Debug will be normal if imports/plugin.go is removed. And dynamic imports work just fine per my run (OSX 10.11 Go1.11).

As golang/go#23733 will seemingly only go into Go1.12 in the future, I would suggest stop shipping imports/plugin.go by default.

[cosmos72]

I'd like delve to support debugging gomacro too, but plugin is used to import third party packages at run-time: without it, only the standard Go library can be imported.

Importing third party packages at run-time is such an essential feature that if I have to choose between it and support to debug gomacro, I would decide for the former every time.

[complyue]

I'm still new to go and just find my check that dynamic import can work without imports/plugin.go is invalid, as I didn't rebuild gomacro. After I go install github.com/cosmos72/gomacro with imports/plugin.go removed, dynamic import does fail, I did have false faith.

And I still want to find a way to have dynamic imports an opt-in which is off by default, as I'm working on https://github.com/complyue/hbigo , which depends on gomacro to establish a hosted scripting env supporting Go syntax/semantics (and gomacro is the only suitable interpreter atm as I researched), I don't want an (micro service mostly) app depending on my lib destined to lose debuggability always.

Especially those micro services are supposed to expose limited Go func/type to be scriptable (i.e. no dynamic imports). The only workaround to gain debuggability for such an app, I figured out so far, is to remove $GOPATH/src/github.com/cosmos72/gomacro/imports/plugin.go after installing gomacro.

It's pitty tweaky and I wanna better solutions.

[cosmos72]

All the solutions coming to my mind for your use case have significant drawbacks:

1. use a different interpreter. There are some around, including at least

• https://github.com/yunabe/lgo - it also includes graphical frontend that you'd need to disable, and it needs by design the plugin package: each statement is compiled with Go compiler into a shared library, then loaded with plugin.Open()
• https://github.com/gijit/gi - converts Go source to Lua, then runs it with LuaJit. It's very fast for an interpreter, but has limited support to import packages.

2. put a customized copy of gomacro into the vendor/ directory of your project, and remove imports/plugin.go from it. Unluckily, since the plugin package provides dynamic code loading, there is no way to load it dynamically "on demand".

[complyue]

@cosmos72 thanks for your insights. lgo is definitely nogo for me, and I don't think the interpreted invocation of micro service funcs will create bottlenecks for me, as long as those funcs themselves run with compiled speed, so lua based or other jits are not attempting to me too. I think I'd stick with gomacro, the tweaky way to debug app can be tolerable in the near future, tho not perfect.