Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: add a facility to peek into the module cache #26717
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
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
go/packages has been using
Just a quick question, because I'm unclear on what I think the answer "should" be here.
How would you expect
It would seem to me the search space for
Would a compromise starting point be that
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.
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.
Yes, to echo @ianthehat, goimports using only the modules refrenced from
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.