cmd/go: module chatter hides actual errors #26152
Labels
modules
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
bcmills
changed the title
|
In order to diagnose the problem, we need to be able to reproduce it. Please provide some more detail.
|
bcmills
added
WaitingForInfo
|
What were the contents of your go.mod before and after you ran vgo mod -vendor? No change. What is the output of vgo list -m for your module?
No change as far as i can tell. |
|
At the risk of asking two dumb questions:
|
|
@rsc not dumb questions of all especially since when I went to answer questions, I realized I omitted some important information that actually helps isolate the problem. So I originally used dep, which defines a dependency on go-yaml like this (note its not using the versioning or gopkg.in) Before i ran vgo build for the first time, I dropped this go.mod in the root directory. Then when I do the vgo build, for the first time this is what is outputted. And here's what's in go.mod file (due to automatic conversation of the dep lock file): Note that the conversion took the dep from github.com/go-yaml/yaml to gopkg.in/yaml.v2. However, in my package the import is github.com/go-yaml/yaml. Because it didn't output an error message, I had not realized that vgo build and vgo install were actually failing at the point this message is printed out: So vgo vendor wasn't just failing, but vgo build was failing as well. Since I always do a vgo install and a previous version of the binary was already in GOBIN, I thought the build was succeeding when it was failing. If I change the import in the go package to gopkg.in/yaml.v2, then vgo mod -vendor and vgo build start working again. |
jaloren
changed the title
|
@rsc updated the title to more accurately describe the problem. I don't know if this ticket is the appropriate place, but some UX feedback here would be that if vgo operation fails it would be really helpful if vgo printed a message like "ERROR - operation X failed because of Y" to stderr. |
|
@jaloren, thanks that's very helpful. One thing I need to do before the release is make the commands far less chatty, so that real errors aren't lost in the noise. If you still have a copy of the full output hiding the error, can you post it? I'll make sure to take care of the non-error prints in the transcript. Thanks. |
|
@rsc here's the output. The last line is the error. |
|
I can see how that didn't look like an error! Thanks. |
rsc
changed the title
bcmills
removed
the
WaitingForInfo
rsc
changed the title
This was referenced Jan 14, 2019
|
Change https://golang.org/cl/172598 mentions this issue: |
|
Perhaps relatedly, I wish I could use |
|
My tentative plan for this for 1.14 is as follows. Print:
Do not print:
|
This turns out to be really redundant with the |
|
Change https://golang.org/cl/204777 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Nov 1, 2019
Suppress “finding” messages unless they are unusually slow, and “extracting” messages always (they almost always occur conjunction with “downloading”, which is already logged). Log “found” messages for module dependencies added to satisfy missing import paths. Log top-level version changes in 'go get' when the selected version is not identical to the version requested on the command line. Updates #26152 Updates #33284 Change-Id: I4d0de60fab58d7cc7df8a2aff05c8b5b2220e626 Reviewed-on: https://go-review.googlesource.com/c/go/+/204777 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
|
Change https://golang.org/cl/213679 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Jan 9, 2020
In CL 204777, I made the "finding" messages in cachingRepo only print after a “longish” delay, on the theory that they would help diagnose slow or stuck fetches. However, as I've been testing Go 1.14 beta 1, I've found that these messages are mostly just noise, and the fact that they are so nondeterministic causes both confusion and test flakes (#35539). Moreover, it currently triggers once for each candidate module, when what we're usually after is actually a specific package within the module. So let's log the package operation unconditionally instead of the module fetches nondeterministically. Fixes #35539 Updates #26152 Change-Id: I41a1c772465b2f0b357d3402bc372b6907773741 Reviewed-on: https://go-review.googlesource.com/c/go/+/213679 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
|
Change https://golang.org/cl/219437 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Feb 21, 2020
…odule added We currently print a "go: finding" line for each missing package during import resolution. However, we are only printing a "go: found" line for each module: if a given module provides multiple packages, we don't indicate the module that we found for the second and later packages. Before this change: $ GO111MODULE=on go get golang.org/x/tools/cmd/html2article@78f9822548c13e2c41cc8039d1492a111240db07 go: found golang.org/x/tools/cmd/html2article in golang.org/x/tools v0.0.0-20190214195451-78f9822548c1 go: finding module for package golang.org/x/net/html go: finding module for package golang.org/x/net/html/atom go: downloading golang.org/x/net v0.0.0-20200202094626-16171245cfb2 go: found golang.org/x/net/html in golang.org/x/net v0.0.0-20200202094626-16171245cfb2 After: $ GO111MODULE=on go get golang.org/x/tools/cmd/html2article@78f9822548c13e2c41cc8039d1492a111240db07 go: found golang.org/x/tools/cmd/html2article in golang.org/x/tools v0.0.0-20190214195451-78f9822548c1 go: finding module for package golang.org/x/net/html/atom go: finding module for package golang.org/x/net/html go: found golang.org/x/net/html in golang.org/x/net v0.0.0-20200202094626-16171245cfb2 go: found golang.org/x/net/html/atom in golang.org/x/net v0.0.0-20200202094626-16171245cfb2 Updates #26152 Updates #33284 Change-Id: I221548749e36bfd6a79efe5edc3645dc5319fd6f Reviewed-on: https://go-review.googlesource.com/c/go/+/219437 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?go version go1.10.3 darwin/amd64 vgo:2018-02-20.1
Does this issue reproduce with the latest release?
yes i built from source today
What operating system and processor architecture are you using (
go env)?What did you do?
vgo mod -vendor
What did you expect to see?
The vendor directory to be populated with the packages defined in my go.mod.
What did you see instead?
The vendor directory is empty after command seemed to download packages.
The text was updated successfully, but these errors were encountered: