package plugin

[Russ Cox]

What is the status of the "plugin" package? Are we committing to its API for Go 1.8?

Russ

[David Crawshaw]

I am happy with the plugin package API.

There are a few bugs in the implementation I would like to fix for 1.8
(CL 29692 fixes one and could use a review). The one that needs some
work has to do with plugin internal naming. None of them require API
changes.

[Ian Lance Taylor]

I'm fine with the plugin.Plugin type.

I wonder whether we should change plugin.Symbol to a struct with
opaque fields, and a method Get() interface{}. I can imagine wanting
to provide other kinds of information attached to Symbol in the
future. David C, what do you think?

Ian

[David Crawshaw]

I am not having much luck imagining anything beyond an addressable
reflect.Value, which you can get from Get today, as it returns a
pointer to the symbol.

If there were though, we could add a method next to Lookup that
returns extra information.

> Ian

[Ian Lance Taylor]

We could, for example, look at the Go type information to return a
reflect.Type for the symbol.

> If there were though, we could add a method next to Lookup that
> returns extra information.

That is true.

Ian

[David Crawshaw]

The reflect.Type is very useful. I've been extracting it using:

sym, err := p.Lookup("Foo")
if err != nil {
log.Fatal(err)
}
t := reflect.ValueOf(sym).Elem().Type()

There are a few lines here (more for functions, where the code needs
to skip calling Elem), but it has the advantage that the plugin
package avoids a dependency on the reflect package.

[roger peppe]

I think the plugin package seems great in principle, but I have had a
play with it with mixed results - it seems somewhat flaky as is.

It is somewhat more restrictive than it seems from the API
description. For example, the name of the plugin file is important -
if you rename it, it won't work. As things are currently, you can't
even load a plugin from an absolute path (issue 17155). I don't think
the name of the file should matter at all when loading the plugin.

You don't seem to be able load a plugin which has the same last element
as one that's already loaded even if it's at a different package path,
in contrast to the usual Go rules (you get a panic - issue 17579).
I think that as with the usual Go rules, the package path should be the
thing that counts. In fact, I think it would probably be best if the
plugin root counted as a unique package every time.

You can get mixed versions of the same package when a plugin
uses a package that's already used by the plugin loader.
I mentioned this to Dave Crawshaw, but I raised an issue too:
issue 17578

I love the idea but I'd really like to see this made a little more
bulletproof.

cheers,
rog.

> --
> You received this message because you are subscribed to the Google Groups "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[David Crawshaw]

Are there any particular issues with the interface as presented by
tip.golang.org/pkg/plugin?

I believe these bugs are known, fixable possibly even before the
freeze, and not specific to the package API. I agree they should all
be fixed before the release.

[roger peppe]

On 25 October 2016 at 13:51, David Crawshaw <craw...@golang.org> wrote:
> Are there any particular issues with the interface as presented by
> tip.golang.org/pkg/plugin?

Apart from the fact that it needs to document that Symbol
isn't always a pointer, it seems great to me.