Join GitHub today
Is module support planned? #20
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
This is a good question.
I suspect there's a chance that the
/cc @dominikh Can you confirm?
If it's indeed possible, a good first step might be to try to implement the API of
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.
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
Edit: I should clarify, I actually meant only the