New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is module support planned? #20

Open
mewmew opened this Issue Oct 7, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@mewmew

mewmew commented Oct 7, 2018

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

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Oct 7, 2018

Contributor

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.

Contributor

dmitshur commented Oct 7, 2018

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.

@dominikh

This comment has been minimized.

Show comment
Hide comment
@dominikh

dominikh Oct 7, 2018

Collaborator

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.

Collaborator

dominikh commented Oct 7, 2018

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.

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Oct 7, 2018

Contributor

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.

Contributor

dmitshur commented Oct 7, 2018

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.

@dominikh

This comment has been minimized.

Show comment
Hide comment
@dominikh

dominikh Oct 7, 2018

Collaborator

@dmitshur It should be straightforward. Use the LoadImports load mode, collect import paths from the returned packages.

Collaborator

dominikh commented Oct 7, 2018

@dmitshur It should be straightforward. Use the LoadImports load mode, collect import paths from the returned packages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment