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: ignore 'go.mod' files in 'testdata' subdirectories when computing module boundaries #27852

Open
bcmills opened this Issue Sep 25, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@bcmills
Member

bcmills commented Sep 25, 2018

Some existing tests of Go tools make use of testdata directories containing a self-contained GOPATH

For those tests to work as expected in module mode, the testdata directories may need to contain go.mod files, but in order for the tests to pass when run from within other modules, those go.mod files should be included in the same module as the test — they should not actually define separate modules.

(There's just one caveat that I know of: at the moment, adding a go.mod file is the easiest way to prune out files whose paths are invalid in the module zip format (see #26672).)

CC: @rsc @myitcv @thepudds

¹ e.g., x/tools/cmd/fiximports/testdata

@bcmills bcmills added this to the Go1.12 milestone Sep 25, 2018

@myitcv

This comment has been minimized.

Member

myitcv commented Sep 25, 2018

but in order for the tests to pass when run from within other modules, those go.mod files should be included in the same module as the test — they should not actually define separate modules.

This bit I don't quite understand, specifically "should be included in the same module as the test". Could you clarify?

That said, with tests that do require a "full setup" (i.e. a go.mod etc) is it not just as easy to create a temporary directory and programmatically create a go.mod within it? Seems a bit easier/cleaner than offering an exemption to the rule?

Or just use _testdata? (I realise this might be contrary to suggested best practice, but again maybe easier to offer a variation on this best practice with the introduction of modules?)

@bcmills

This comment has been minimized.

Member

bcmills commented Sep 25, 2018

This bit I don't quite understand, specifically "should be included in the same module as the test". Could you clarify?

If I add a require golang.org/x/tools to my go.mod file and then run go test golang.org/x/tools/cmd/fiximports, the test should pass. That implies that the source directory within the module cache must include the entire testdata directory.

That said, with tests that do require a "full setup" (i.e. a go.mod etc) is it not just as easy to create a temporary directory and programmatically create a go.mod within it?

That is a straightforward workaround, but it splits the test input across two places (the testdata directory and the code to generate the go.mod files), and makes it so that you can't just cd testdata and export GOPATH=$(pwd) to investigate the (accurate) contents of the test directory.

@gopherbot

This comment has been minimized.

gopherbot commented Sep 26, 2018

Change https://golang.org/cl/137815 mentions this issue: all: set GO111MODULE=off for tests that use GOPATHs in testdata.

@bcmills

This comment has been minimized.

Member

bcmills commented Sep 27, 2018

Note from @rsc: if we do this, we should also reject module paths that include a testdata component.

gopherbot pushed a commit to golang/tools that referenced this issue Oct 3, 2018

all: set GO111MODULE=off for tests that use GOPATHs in testdata.
Some users may set GO111MODULE=on, and we will eventually want to be able to
build x/tools itself in module mode.

Updates golang/go#27858
Updates golang/go#27852

Change-Id: Iaf488b2a89e6526471530245cb580f1f0391a770
Reviewed-on: https://go-review.googlesource.com/137815
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>

@bcmills bcmills modified the milestones: Go1.12, Go1.13 Nov 14, 2018

@rsc

This comment has been minimized.

Contributor

rsc commented Nov 20, 2018

I don't know that we should introduce a special case here. We have a very simple rule at the moment. Maybe we should figure out how to work within that rule.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment