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

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

stamblerre opened this issue May 20, 2020 · 4 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.

@dlsniper
Copy link
Contributor

@dlsniper dlsniper commented Aug 20, 2020

I have a similar problem, but I'm not sure if my use-case fits in this issue or needs to be addressed in a separate issue.

When I list the dependencies of a Go modules based project, e.g. Delve, with GOPROXY=off by running this command:

go list -m -json -mod=vendor all

I receive the following error:

go list -m: can't compute 'all' using the vendor directory
        (Use -mod=mod or -mod=readonly to bypass.)

If I use the suggested -mod=mod or -mod=readonly then I'll receive an error similar to this:

go: github.com/cosiner/argv@v0.1.0: module lookup disabled by GOPROXY=off

When compiling the application with a command like the one below, the command finishes successfully:

go build -mod=vendor -o=my-delve github.com/go-delve/delve/cmd/dlv

If I set the GOPROXY=proxy.golang.org,direct, then go list downloads the dependencies and then lists them from the GOMODCACHE. This is not what I want or need.

So, the problem seems to be go lists's inability to list the dependencies when using -mod=vendor and/or work with GOPROXY=off. The -e flag does not seem to do anything in this case.

As such, I propose that go list should continue to work and list the vendored modules/dependencies when GOPROXY=off and -mod=vendor flags are present. If I need to add -e to the go list command, that's OK too.

This problem also hampers users of editors such as GoLand. It is impossible for the IDE to list the vendored dependencies and have access to their version, without parsing the vendor/modules.txt file. To the best of my knowledge, the file format is not stable, or well documented, which means it can change at any time (please correct me if my assumption is incorrect).

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
4 participants
You can’t perform that action at this time.