change Options.GoPath to Options.Build of type build.Context.

[james-lawrence]

Proposal

// Options are the interpreter options.
type Options struct {
	// GoPath sets GOPATH for the interpreter
	GoPath string
	// BuildTags sets build constraints for the interpreter
	BuildTags []string
}

consider:

// Options are the interpreter options.
type Options struct {
	Build build.Context
}

type is basically just feeding details to an internal build.Context. there is no reason to encapsulate build.Context, its part of the standard runtime. its confusing and unnecessary.

[mvertes]

Most of build.Context data are relevant for the go compiler, and not at all for the interpreter. I find it wrong to expose all of it as part of the interpreter API, which we should keep as minimal as possible. For now, I think it is better to expose only relevant fields which make sense in the context of the interpreter.

[james-lawrence]

that's a short sighted approach. yaegi has to effectively build the program, and all of build.Context is relevant to that. zero reason to reinvent the wheel, which is exactly what is being done here.

about the only thing that isn't relevant to yaegi are machine specific issues, and doesn't hurt anything to expose a standard lib api even if you don't use it all.