Allow to import from Go modules
foxcpp opened this issue · comments
It would be nice to be able to import packages from Go module in current directory.
My use case is launching gomacro from project directory to interactively test functions.
What do you think?
Hello,
do you mean adding some special syntax, as for example import "." to import the package in the current directory?
At the moment the current directory is not considered special, so you have to import it using its full path:
import "path/to/my/package"
Sure, but it doesn't works if using Go 1.11 modules, it just says "error loading package "..." metadata". Obviously because package is not in GOPATH.
hmm... did you try running "go install" in the module directory before starting gomacro?
I admit I have very little experience with Go 1.11 modules...
hmm... did you try running "go install" in the module directory before starting gomacro?
yes
I admit I have very little experience with Go 1.11 modules...
And I have zero experience with Go tooling libraries.
But from what I understand, tools should use https://godoc.org/golang.org/x/tools/go/packages for package loading to get modules support.
At the moment I am using go/importer.Default
I will give a try to the tool you mentioned, thanks :)
I guess there is a problem with loading on non-Linux platforms (gomacros basically needs to be recompiled with package you want to use included, right?). I wonder if this can work with modules.
Say, I have a project A which depends on github.com/foo/bar v1.1.
If I run gomacro from directory of project A, I want to be able to import v1.1 version of dependency using path "github.com/foo/bar".
But if I launch gomacro from directory of project B which depends on github.com/foo/bar v1.0 (or even better, v2.0), I want to get v1.0 (v2.0) version of "github.com/foo/bar".
This leads to a problem, if we are on, say, Windows. How should we compile-in these "foo/bars"? Can we do it all? Can we include both?
Working on it.
It will also require the plugin package, like the current (non-module-aware) implementation of import.
So it cannot work on Windows
Commit caa3eae adds support to import from Go modules.
It requires compiling gomacro with Go >= 1.11, and having the (same) Go toolchain available at runtime.
Oh, and it works only on Linux and Mac OS X, because on other platforms plugin.Open() is not supported.
There is still no special support to load modules from the current directory, but it's now trivial to implement - I will do it ASAP
@cosmos72, did you ever implement "special support to load modules from the current directory"? I'm having a hard time with gomacro code generation in my module...
Not yet
@cosmos72
I think that this (newer fork here) could replace the plugin imports in gomacro and could work also on windows.
On windows the compilation would look like go tool compile -I GOPATH\pkg\windows_amd64 GOPATH\src\gomacro.imports\github.com\some-external\reponame\reponame.go
and then maybe could be loaded when the loader would be embedded in gomacro instead of plugin usage when it would be accessed like this which looks similar to how you import the reflected types from the shared libraries of the imports.
goloader seems to be a very interesting project!
Thanks for the suggestion, I will try it.
If it works as advertised, it could really be used instead of plugin. Since it is states to also support Windows, we could finally load third party packages also on Windows without recompiling gomacro.
Yes, but unfortunately the code is very complex and it requires copying cp -r $GOROOT/src/cmd/internal $GOROOT/src/cmd/objfile before compilation, maybe there could be folder forks of the supported go revisions of the official golang stable release versions that are renamed such that internal is not in the name anymore (that's blocked "by design"), then it would compile like a normal go package.
Also it seems that there are problems with interfaces: dearplain/goloader#6 (comment)
Yes, but unfortunately the code is very complex and it requires copying
cp -r $GOROOT/src/cmd/internal $GOROOT/src/cmd/objfilebefore compilation, maybe there could be folder forks of the supported go revisions of the official golang stable release versions that are renamed such thatinternalis not in the name anymore (that's blocked "by design"), then it would compile like a normal go package.
Also it seems that there are problems with interfaces: dearplain/goloader#6 (comment)
@Tim-St i already rewrite relocate interfaces, it will be work better