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

Jump to bottom

cmd/go: skip finding external test dependencies for go build #29725

Closed
anjmao opened this issue Jan 14, 2019 · 5 comments
Closed

cmd/go: skip finding external test dependencies for go build #29725

anjmao opened this issue Jan 14, 2019 · 5 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@anjmao
Copy link

anjmao commented Jan 14, 2019

What version of Go are you using (go version)?

go version go1.11.2 darwin/amd64

What did you do?

  1. I'm using go-nio/nio http library which doesn't have any external runtime dependencies. It only uses testify for unit tests.
package main

import (
	"net/http"
	"github.com/go-nio/nio"
)

func main() {
	n := nio.New()
	http.ListenAndServe(":80", n)
}
  1. Now I'm build my app using go build for production. I'm not running any go-nio/nio library tests.

What did you expect to see?

Now I expect go build output to show only runtime dependencies.

go: finding github.com/go-nio/nio v1.0.2
go: downloading github.com/go-nio/nio v1.0.2

What did you see instead?

Instead I see all dependencies including external library test dependencies.

go: finding github.com/go-nio/nio v1.0.2
go: finding github.com/stretchr/testify v1.3.0
go: finding github.com/stretchr/testify v1.2.2
go: finding github.com/pmezard/go-difflib v1.0.0
go: finding github.com/davecgh/go-spew v1.1.1
go: finding github.com/stretchr/objx v0.1.1
go: finding github.com/davecgh/go-spew v1.1.0
go: finding github.com/stretchr/objx v0.1.0
go: downloading github.com/go-nio/nio v1.0.2
@mvdan mvdan added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. modules labels Jan 14, 2019
@mvdan
Copy link
Member

mvdan commented Jan 14, 2019

/cc @bcmills

@bcmills
Copy link
Contributor

bcmills commented Jan 14, 2019

All modules in the module graph can affect the selected versions of other modules, so we must have at least the go.mod file (but not necessarily the rest of the source code) for each module in order to resolve version selection.

Test dependencies must be included in the module graph: without them, test results are not reproducible.

The go build output is certainly too chatty (#26152), but beyond that this is working as designed.

@bcmills bcmills closed this as completed Jan 14, 2019
@anjmao
Copy link
Author

anjmao commented Jan 15, 2019

@bcmills Thanks for response. But as you said

Test dependencies must be included in the module graph: without them, test results are not reproducible.

As I mentioned I'm not running any tests, that tests results do you have in mind?

The problem is that there is no way to describe dependency as being used only for tests. Why not add special comment like test so go build can skip fetching go.mod files for whose packages?

require (
	github.com/davecgh/go-spew v1.1.1 // test indirect
	github.com/pmezard/go-difflib v1.0.0 // test indirect
	github.com/stretchr/objx v0.1.1 // test indirect
	github.com/stretchr/testify v1.2.2 // test
)

@bcmills
Copy link
Contributor

bcmills commented Jan 15, 2019

go build can't skip the process of deciding which versions to use, and “test-only” dependencies can affect that decision.

Those go.mod files should be tiny, and they'll stay in your module cache after the first time you fetch them.

@bcmills
Copy link
Contributor

bcmills commented Jan 16, 2019

The problem is that there is no way to describe dependency as being used only for tests.

See #26955.

@golang golang locked and limited conversation to collaborators Jan 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@anjmao @mvdan @bcmills @gopherbot