Skip to content
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

proposal: x/tools/go/packages: add module information to the Package struct #38446

Closed
matloob opened this issue Apr 14, 2020 · 4 comments
Closed

Comments

@matloob
Copy link
Contributor

matloob commented Apr 14, 2020

This is proposal 2 of 3 coming out of the discussion of issue #38234.

We propose adding a pointer to new struct containing module information to the Package struct. This struct might be the Module struct reported by go list, or another struct defined in x/tools/go/packages or somewhere in x/mod.

go/packages was originally conceived as being build-system independent, and not all build systems use modules. But now, even Bazel supports modules, and even if a user isn't using modules for their own build, they need to produce modules for consumers of their libraries. Given how widespread the use of modules is, and how modules can be used across build systems, it seems reasonable to add information about a package's module (if it has one) to its Package struct.

If this proposal were accepted, we'd also need to add a Need bit to request a module, and give users the expectation that module information might not always be present.

@a8m
Copy link
Contributor

a8m commented Apr 15, 2020

Hey @matloob, is it a duplicate of #35921?

@matloob
Copy link
Contributor Author

matloob commented Apr 16, 2020

It's pretty close. If you want, I can retitle #35921 and close this issue in favor of that one.

The main remaining differences are that we still need to discuss exactly what struct we're putting in Package (module public is unexported, and whichever struct we pick should probably be defined in x/mod), and that we'd need a Need bit for the field.

@a8m
Copy link
Contributor

a8m commented Apr 18, 2020

modinfo.ModulePublic is technically unexported, but it's publicly visible (using go list) and this why I've picked it.

It's pretty close. If you want, I can retitle #35921 and close this issue in favor of that one.

Yeah, let's close this one and retitle #35921. I'll continue the discussion there.

@matloob
Copy link
Contributor Author

matloob commented Apr 22, 2020

Okay, I'm closing this issue in favor of #35921.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants