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 · 9 comments
Open

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

matloob opened this issue Jul 31, 2018 · 9 comments
Labels
FeatureRequest modules NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@matloob
Copy link
Contributor

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 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

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 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 Feedback is required from experts, contributors, and/or the community before a change can be made. labels Jul 31, 2018
@sam3d
Copy link

sam3d commented Aug 2, 2018

(related #24661)

@ianlancetaylor ianlancetaylor added this to the Go1.12 milestone Aug 3, 2018
@bcmills bcmills modified the milestones: Go1.12, Go1.13 Oct 24, 2018
@bcmills
Copy link
Contributor

bcmills commented Jan 18, 2019

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

@bcmills
Copy link
Contributor

bcmills commented Jan 18, 2019

CC @heschik

@bcmills
Copy link
Contributor

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.

@dolmen
Copy link
Contributor

dolmen commented Mar 16, 2023

#43646 suggests to add GOPROXY=cache for a distinct behaviour from GOPROXY=off.

@dolmen
Copy link
Contributor

dolmen commented Mar 16, 2023

Note that the directory structure of the module cache is officially documented at https://go.dev/ref/mod#module-cache. Can we interpret this as some stability guarantee?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest modules NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests

10 participants