-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/go: go module fetching gives unexpected stderr output #36297
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
Comments
On closer inspection, this is not just on |
I'm afraid that changes like this will break more existing things because currently $ go mod download -json golang.org/x/text@v0.3.2
go: finding golang.org/x/text v0.3.2
{
"Path": "golang.org/x/text",
"Version": "v0.3.2",
"Info": "/Users/aofei/go/pkg/mod/cache/download/golang.org/x/text/@v/v0.3.2.info",
"GoMod": "/Users/aofei/go/pkg/mod/cache/download/golang.org/x/text/@v/v0.3.2.mod",
"Zip": "/Users/aofei/go/pkg/mod/cache/download/golang.org/x/text/@v/v0.3.2.zip",
"Dir": "/Users/aofei/go/pkg/mod/golang.org/x/text@v0.3.2",
"Sum": "h1:tW2bmiBqwgJj/UpqtC8EpXEZVYOwU0yG4iWbprSVAcs=",
"GoModSum": "h1:bEr9sfX3Q8Zfm5fL9x+3itogRgK3+ptLWKqgva+5dAk="
} Only the JSON part is what we're going to process as a successful output. If we also move |
@carlpett sorry, but I dare to add that
this is not only about go, many "defacto-standard" tools use stderr as output for secondary information, ranging from
I think this (your ci pipeline or tools) should be fixed instead. We usually set up CI so that it detects failure by non-zero return code, rather than by output to stderr. Though I do vaguely remember one or two tools who have such behavior as you describe by default. I believe most of them have some setting about this at least. You can name some specific tool you want to have better integration with so we can look closer... |
Thanks for those perspectives @aofei and @RodionGork! As always, there are more nuances than initially expected :) Anyway, the initial issue topic about mod download writing other things to stderr than what is explicitly documented (a quick look indicated most other commands don't document thier outputs at all) might be worth doing something about? |
Well, this may be worthwile, if there is some specific text in documentation which could be improved / extended... Do you mean this line? Regretfully such comments easily become obsolete unless they have corresponding unit-test (which may show that empty stderr is desired and important). So I'm not sure, to which side this should be fixed (e.g. perhaps removing this line as it contradicts current behavior) :( |
/cc @bcmills @jayconrod |
For All module-related commands may print messages related to network operations to stderr. |
Change https://golang.org/cl/213134 mentions this issue: |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
go mod download
What did you expect to see?
As per the documentation of the command,
I expected no output on success.
What did you see instead?
A line to stderr for each module as it is cached:
Discussion
This appears to come from here:
go/src/cmd/go/internal/modfetch/cache.go
Line 171 in dcd3b2c
This is an issue since many many CI tools will fail the build on output to stderr. We could redirect to stdout, but then actual errors might be missed (although that probably triggers a fail based on exit code).
The smallest possible fix would be to update the documentation so that it mentions that caching will also write to stderr, but a "better" fix from my point of view would be to either move the caching logs to stdout, and/or hide them completely unless a verbose flag is passed?
The text was updated successfully, but these errors were encountered: