kisielk
Is module support planned?
First off, I'd like to extend a thank you. This library what exactly what I was looking for! Basically a library that expands patterns for specifying packages in the exact same way as the Go compiler does. It's perfect!
Now, for the question. Are there any plans to support modules? (or is it already supported under the hood?)
I'd love to avoid re-implement module support (or rather my own interpretation of how I think module support works). Rather, it would be great if the exact semantics of the Go compiler for handling modules were exposed. And perhaps this would fit the purpose of the gotool package rather well?
Kindly, Robin
This is a good question.
I suspect there's a chance that the golang.org/x/tools/go/packages should be used to do what gotool does while adding support for modules, and gotool can be eventually deprecated (i.e., in a few years, when Go 1.15 or so is released).
/cc @dominikh Can you confirm?
If it's indeed possible, a good first step might be to try to implement the API of gotool via go/packages on with go1.11 build constraint.
People should probably migrate go go/packages as soon as it matches their needs, yeah.
Implementing module support in this package isn't really a viable option. We could copy over a lot more code from cmd/go, but go/packages made it obvious that we're moving on to a new model, asking the underlying build systems. And manually implementing module support by using go/packages is out of scope; the purpose of this package was to export code from cmd/go, with as few changes as possible.
IMO gotool can be considered deprecated, and anything that wants to support modules, or Blaze/Bazel, should migrate to go/packages proper.
And manually implementing module support by using go/packages is out of scope;
Not disagreeing with your main point here, but I'd like to learn the answer to the following question. Do you have a sense of how hard would it be to implement the current API using go/packages? I might be interested in finding that out.
Edit: I should clarify, I actually meant only the func ImportPaths(args []string) []string subset of the API. I expect that arbitrary modifications to build.Context away from build.Default would be impossible to support. Well, this is already a good answer to my question.
@dmitshur It should be straightforward. Use the LoadImports load mode, collect import paths from the returned packages.
4 years later, I am trying to update a usage of gotool.ImportPaths(flag.Args())
Is there a new way to do this?
It has been a while since I used go, and I am struggling to find the go/packages that is referred to
It has been a while since I used go, and I am struggling to find the go/packages that is referred to
Welcome back to the Go community Walter :)
Wish you happy coding!
Cheers, Robin
It has been a while since I used go, and I am struggling to find the go/packages that is referred to
Welcome back to the Go community Walter :)
Wish you happy coding!
Cheers, Robin
Thanks so much and sorry to disappoint. Working on a presentation about goderive, but that is the only Go in my near term future. But it has been pretty fun/surreal to feel like I know what I am doing for a change.
When looking at this in more detail, it looks like pretty large refactor would be needed and even after that it seems the code would need to be refactored again to not use LoadImports
// Deprecated: LoadImports exists for historical compatibility
gotool.ImportPaths simply expands the paths ([]string -> []string) to something that can be used by golang.org/x/tools/go/loader and from then on I need *loader.Program throughout quite a large part of my code base, which I don't know how golang.org/x/tools/go/packages is going to get me to.
I think I will stick with using gotool for now, until someone asks for module support at least. It still worked really well for the talk. Thanks for all the work on this tool <3