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: return best-effort results despite inconsistent vendoring #39164

Open
stamblerre opened this issue May 20, 2020 · 3 comments
Open

cmd/go: return best-effort results despite inconsistent vendoring #39164

stamblerre opened this issue May 20, 2020 · 3 comments

Comments

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 20, 2020

Following up on #39100, is it possible for the go command to return partial results even with an inconsistent vendor folder? This is done in several (arguably smaller) cases, like #35973 and #38846.

If go list could return partial results along with the error, that would make the experience in gopls much better for users. Right now, our best option will be to show the user a pop-up with the error message and a button that, when clicked, runs go mod vendor. This work-around is fine for now, but I wonder if there is a better longterm solution.

/cc @bcmills @jayconrod @heschik

@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented May 20, 2020

cc @matloob

Tentatively milestoning for 1.16. @bcmills could confirm feasibility of this though.

I think this is possible, but it will make looking up which module provides each package unreliable. We'd probably only want to do this with go list -e. That would work for gopls though, right?

@stamblerre
Copy link
Contributor Author

@stamblerre stamblerre commented May 20, 2020

Thanks!

I think this is possible, but it will make looking up which module provides each package unreliable. We'd probably only want to do this with go list -e. That would work for gopls though, right?

Yep, gopls uses -e.

@bcmills
Copy link
Member

@bcmills bcmills commented May 20, 2020

Yes, I think this is feasible. The fix will be to move the inconsistent vendoring error from one that occurs at module loading time to one that applies to individual packages and/or patterns.

I think it will suffice to apply the error to every package loaded from the vendor directory, plus any wildcard patterns that could match packages outside of the standard library. All other packages (such as those loaded from std and from the main module) should be unaffected by inconsistent vendoring anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.