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

cmd/go: add a facility to peek into the module cache #26717

Open
matloob opened this issue Jul 31, 2018 · 7 comments
Open

cmd/go: add a facility to peek into the module cache #26717

matloob opened this issue Jul 31, 2018 · 7 comments
Labels
FeatureRequest modules NeedsDecision
Milestone

Comments

@matloob
Copy link
Contributor

@matloob matloob commented Jul 31, 2018

cc: @rsc @bcmills @suzmue @ianthehat

To work with modules, a tool like goimports should be aware of the set of modules in the module cache. Then, it could suggest packages that haven't been required in go.mod or imported by a package or its deps. At the least, it should be able to list the latest version of each module in the user's module cache. (And if GOPROXY is set, it should be able to list the latest version of the modules served by the proxy.)

Currently there doesn't seem to be a way for a tool like goimports to suggest packages outside the transitive module dependencies of the current module without guessing the module cache directory (which is changing: golang.org/cl/126755) and then crawling through the directories. It seems like the directory layout may be stable but finding the directory is a bit dodgy. And we'd need to handle goproxy manually too.

go/packages has been using go list to find metadata about packages, so ideally we could use go list or maybe go mod to get at this information. But maybe there's a better way to get at it.

@myitcv
Copy link
Member

@myitcv myitcv commented Jul 31, 2018

Just a quick question, because I'm unclear on what I think the answer "should" be here.

How would you expect goimports to respond in the presence of multiple (major) versions of a module (and therefore the packages it contains)?

It would seem to me the search space for goimports as it currently works increases massively as a result of modules.

Would a compromise starting point be that goimports works with the modules referenced from go.mod?

@ianthehat
Copy link

@ianthehat ianthehat commented Jul 31, 2018

The trouble is, that's a strictly worse experience than the existing one...

Currently, if you start a new project, you make a new directory and type some code.
When you run goimports, it gets to see all the packages you have ever used, and pick your imports based on those, which is mostly likely to contain the ones you want because most people work on similar things using similar packages.
You are also likely to have used go get to check out some examples of the kinds of things you want to do, which will also prime the search space.

In the world of modules, all that information disappears, each new module starts with no imports, and so goimports will not do anything for you.

The search space is not that large, you don't need to worry at all about minor versions, you just need to know what import paths have entries in the module cache, you will check whatever version would be added by mvs if the import is added to the file, because that is what you will be doing, goimports will never write the module file for you.

Major versions are the same problem go imports would currently face if you checked out the modules to your go path anyway, two different packages of the same name, pick the best one, something it already has to do. We probably have to add some logic to bias towards larger major versions when you have multiple fully matching candidates, but we would have to do that even if you were still using GOPATH rather than the module cache.

@matloob
Copy link
Contributor Author

@matloob matloob commented Jul 31, 2018

Yes, to echo @ianthehat, goimports using only the modules refrenced from go.mod would be a major regression for users.

As I understand it, different major versions of a module are considered as distinct modules in pretty much every way. And goimports might want to add some heuristic that might prefer the later major version when both are in the module cache, but it's mostly the same problem as a fork of a module, or (in the GOPATH world) the fork of a package.

@ALTree ALTree added modules NeedsDecision labels Jul 31, 2018
@sam3d
Copy link

@sam3d sam3d commented Aug 2, 2018

(related #24661)

@ianlancetaylor ianlancetaylor added this to the Go1.12 milestone Aug 3, 2018
@bcmills bcmills removed this from the Go1.12 milestone Oct 24, 2018
@bcmills bcmills added this to the Go1.13 milestone Oct 24, 2018
@bcmills
Copy link
Member

@bcmills bcmills commented Jan 18, 2019

Would #26718 address all of the known use-cases for this, or are there others?

@bcmills
Copy link
Member

@bcmills bcmills commented Jan 18, 2019

CC @heschik

@andybons andybons removed this from the Go1.13 milestone Jul 8, 2019
@andybons andybons added this to the Go1.14 milestone Jul 8, 2019
@rsc rsc removed this from the Go1.14 milestone Oct 9, 2019
@rsc rsc added this to the Backlog milestone Oct 9, 2019
@bcmills
Copy link
Member

@bcmills bcmills commented Jan 24, 2020

#32337 suggests GOPROXY=off as one way we could allow users to explicitly request to resolve packages and/or module versions using only the existing contents of the module cache.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest modules NeedsDecision
Projects
None yet
Development

No branches or pull requests

9 participants