-
Notifications
You must be signed in to change notification settings - Fork 257
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
TestMixedMageImports fail on macOS in modules mode (current master) #224
Comments
Sorry, missed this when it was first filed. It works for me on my mac, but I'm not using modules, that may be the problem. |
Right, the test passes if I run it from |
Note this doesn't seem to be mac specific. This also is causing failures on travis with $ docker run -it --rm -v "$(pwd):/mage" -w /mage golang:1.12 go test -v -run TestMixedMageImports ./mage/...
=== RUN TestMixedMageImports
--- FAIL: TestMixedMageImports (0.12s)
main_test.go:249: expected to exit with code 0, but got 1, stderr: build command-line-arguments: cannot find module for path _/mage/mage/testdata/mixed_lib_files/subdir
Error: error compiling magefiles
main_test.go:254: expected "Targets:\n build \n" but got ""
FAIL
FAIL github.com/magefile/mage/mage 0.132s Throwing it in the proper place in docker run -it --rm -v "$(pwd):/go/src/github.com/magefile/mage" -w /go/src/github.com/magefile/mage golang:1.12 go test -v -run TestMixedMageImports ./mage/...
=== RUN TestMixedMageImports
--- PASS: TestMixedMageImports (0.33s)
PASS
ok github.com/magefile/mage/mage 0.347s |
So you can sort of work around this by adding |
Ah, so the definition of I was able to work around this with this patch: diff --git a/.travis.yml b/.travis.yml
index f7e0703..895ed9b 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -9,12 +9,15 @@ branches:
# library, I'm not going to worry about older versions for now.
go:
- tip
+ - 1.12.x
- 1.11.x
- 1.10.x
- 1.9.x
- 1.8.x
- 1.7.x
+go_import_path: github.com/magefile/mage
+
# don't call go get ./... because this hides when deps are
# not packaged into the vendor directory.
install: true
diff --git a/mage/main_test.go b/mage/main_test.go
index 286557e..0d97535 100644
--- a/mage/main_test.go
+++ b/mage/main_test.go
@@ -236,6 +236,32 @@ func TestListMagefilesLib(t *testing.T) {
}
func TestMixedMageImports(t *testing.T) {
+ // Go 1.13+ changes how GO111MODULE behaves. In 1.13, it defaults
+ // to `auto`, which enables Go Module functionality if the working
+ // directory contains a `go.mod` file, or is a subdirectory of a
+ // directory that contains a `go.mod file`.
+ //
+ // This test should be fixed to work in modules mode, but for now
+ // we can work around it by forcing `GO111MODULE` to `off` for
+ // this specific test.
+ go111module, set := os.LookupEnv("GO111MODULE")
+
+ if err := os.Setenv("GO111MODULE", "off"); err != nil {
+ t.Fatalf("Failed to disable go modules for flaky test")
+ }
+
+ defer func() {
+ var err error
+ if set {
+ err = os.Setenv("GO111MODULE", go111module)
+ } else {
+ err = os.Unsetenv("GO111MODULE")
+ }
+ if err != nil {
+ t.Fatalf("Failed to reset go module status")
+ }
+ }()
+
stderr := &bytes.Buffer{}
stdout := &bytes.Buffer{}
inv := Invocation{ |
What's weird is if I force that test to run with $ docker run -it --rm -v "$(pwd):/mage" -w /mage golang:1.12 go test -v -run TestMixedMageImports ./mage/...
=== RUN TestMixedMageImports
DEBUG: 01:43:14.054702 found target Build
DEBUG: 01:43:14.054739 time parse Magefiles: 3.0577ms
--- FAIL: TestMixedMageImports (0.18s)
main_test.go:278: expected to exit with code 0, but got 1, stderr: build command-line-arguments: cannot find module for path _/mage/mage/testdata/mixed_lib_files/subdir
Error: error compiling magefiles
main_test.go:283: expected "Targets:\n build \n" but got ""
FAIL
FAIL github.com/magefile/mage/mage 0.193s |
Ooo, progress. I think I have a fix for this. I hacked in some of the extra debugging to get some more verbose output, but that didn't help too much, so you can ignore that. Changing
to import "github.com/magefile/mage/mage/testdata/mixed_lib_files/subdir" works on golang/go C:\Users\Nathan\projects\mage [test/fix-test-failure +0 ~3 -0 !]
λ docker run -it --rm -v "$(pwd):/mage" -w /mage -e GO111MODULE=auto golang:master go test -v -run TestMixedMageImports ./mage/...
=== RUN TestMixedMageImports
DEBUG: 02:50:40.833023 getting all non-mage files in ./testdata/mixed_lib_files
DEBUG: 02:50:40.848897 found non-mage files lib.go
DEBUG: 02:50:40.848913 marked file as non-mage: "lib.go"
DEBUG: 02:50:40.848915 getting all files plus mage files
DEBUG: 02:50:40.866672 time to scan for Magefiles: 33.6508ms
DEBUG: 02:50:40.866707 found magefiles: testdata/mixed_lib_files/mage_helpers.go, testdata/mixed_lib_files/magefile.go
DEBUG: 02:50:40.871552 output exe is /tmp/065651766/c92da59d59823ebbd68ab563dbfaf0afe36ab312
DEBUG: 02:50:40.875778 build cache exists, will ignore any compiled binary
DEBUG: 02:50:40.875806 parsing files
DEBUG: 02:50:40.878311 found target Build
DEBUG: 02:50:40.878351 time parse Magefiles: 2.5399ms
DEBUG: 02:50:40.878358 Creating mainfile at testdata/mixed_lib_files/mage_output_file.go
DEBUG: 02:50:40.879989 writing new file at testdata/mixed_lib_files/mage_output_file.go
About to compile [testdata/mixed_lib_files/mage_helpers.go testdata/mixed_lib_files/magefile.go testdata/mixed_lib_files/mage_output_file.go]
DEBUG: 02:50:40.882821 compiling to /tmp/065651766/c92da59d59823ebbd68ab563dbfaf0afe36ab312
DEBUG: 02:50:40.882824 compiling using gocmd: go
DEBUG: 02:50:40.889598 running go build -o /tmp/065651766/c92da59d59823ebbd68ab563dbfaf0afe36ab312 mage_helpers.go magefile.go mage_output_file.go
DEBUG: 02:50:41.195399 time to compile Magefile: 305.7445ms
Running compiled binary
DEBUG: 02:50:41.196286 running binary /tmp/065651766/c92da59d59823ebbd68ab563dbfaf0afe36ab312
DEBUG: 02:50:41.196298 running magefile with mage vars:
MAGEFILE_CACHE=/tmp/065651766
MAGEFILE_VERBOSE=1
MAGEFILE_LIST=1
MAGEFILE_DEBUG=1
MAGEFILE_GOCMD=go
--- PASS: TestMixedMageImports (0.37s)
PASS
ok github.com/magefile/mage/mage 0.379s
C:\Users\Nathan\projects\mage [test/fix-test-failure +0 ~4 -0 !]
λ docker run -it --rm -v "$(pwd):/go/src/github.com/magefile/mage" -w /go/src/github.com/magefile/mage -e GO111MODULE=auto golang:master go test -v -run TestMixedMageImports ./mage/...
=== RUN TestMixedMageImports
DEBUG: 02:50:47.814008 getting all non-mage files in ./testdata/mixed_lib_files
DEBUG: 02:50:47.830877 found non-mage files lib.go
DEBUG: 02:50:47.830911 marked file as non-mage: "lib.go"
DEBUG: 02:50:47.830914 getting all files plus mage files
DEBUG: 02:50:47.848404 time to scan for Magefiles: 34.3905ms
DEBUG: 02:50:47.848452 found magefiles: testdata/mixed_lib_files/mage_helpers.go, testdata/mixed_lib_files/magefile.go
DEBUG: 02:50:47.854094 output exe is /tmp/583154524/c92da59d59823ebbd68ab563dbfaf0afe36ab312
DEBUG: 02:50:47.859194 build cache exists, will ignore any compiled binary
DEBUG: 02:50:47.859222 parsing files
DEBUG: 02:50:47.862175 found target Build
DEBUG: 02:50:47.862216 time parse Magefiles: 2.9874ms
DEBUG: 02:50:47.862223 Creating mainfile at testdata/mixed_lib_files/mage_output_file.go
DEBUG: 02:50:47.863877 writing new file at testdata/mixed_lib_files/mage_output_file.go
About to compile [testdata/mixed_lib_files/mage_helpers.go testdata/mixed_lib_files/magefile.go testdata/mixed_lib_files/mage_output_file.go]
DEBUG: 02:50:47.866445 compiling to /tmp/583154524/c92da59d59823ebbd68ab563dbfaf0afe36ab312
DEBUG: 02:50:47.866449 compiling using gocmd: go
DEBUG: 02:50:47.872456 running go build -o /tmp/583154524/c92da59d59823ebbd68ab563dbfaf0afe36ab312 mage_helpers.go magefile.go mage_output_file.go
DEBUG: 02:50:48.175216 time to compile Magefile: 302.7146ms
Running compiled binary
DEBUG: 02:50:48.176137 running binary /tmp/583154524/c92da59d59823ebbd68ab563dbfaf0afe36ab312
DEBUG: 02:50:48.176154 running magefile with mage vars:
MAGEFILE_CACHE=/tmp/583154524
MAGEFILE_VERBOSE=1
MAGEFILE_LIST=1
MAGEFILE_DEBUG=1
MAGEFILE_GOCMD=go
--- PASS: TestMixedMageImports (0.36s)
PASS
ok github.com/magefile/mage/mage 0.376s I think this is just due to go not liking relative imports, regardless of where the code is in the |
Yeah, I tested this on all versions tested by Travis and it works for all of them: Test ResultsC:\Users\Nathan\projects\mage [master ≡ +0 ~2 -0 !]
λ @(@(7..12) | ForEach-Object { "1.$_" }) + "master" | foreach-object { "Testing golang $_"; docker run -it --rm -v "$(pwd):/go/src/github.com/magefile/mage" -w /go/src/github.com/magefile/mage "golang:$_" go test -v -run TestMixedMageImports ./mage/... }
Testing golang 1.7
=== RUN TestMixedMageImports
--- PASS: TestMixedMageImports (0.41s)
PASS
ok github.com/magefile/mage/mage 0.424s
Testing golang 1.8
=== RUN TestMixedMageImports
--- PASS: TestMixedMageImports (0.36s)
PASS
ok github.com/magefile/mage/mage 0.377s
Testing golang 1.9
=== RUN TestMixedMageImports
--- PASS: TestMixedMageImports (0.36s)
PASS
ok github.com/magefile/mage/mage 0.377s
Testing golang 1.10
=== RUN TestMixedMageImports
--- PASS: TestMixedMageImports (0.30s)
PASS
ok github.com/magefile/mage/mage 0.312s
Testing golang 1.11
=== RUN TestMixedMageImports
--- PASS: TestMixedMageImports (0.33s)
PASS
ok github.com/magefile/mage/mage 0.346s
Testing golang 1.12
=== RUN TestMixedMageImports
--- PASS: TestMixedMageImports (0.36s)
PASS
ok github.com/magefile/mage/mage 0.375s
Testing golang master
=== RUN TestMixedMageImports
--- PASS: TestMixedMageImports (0.35s)
PASS
ok github.com/magefile/mage/mage 0.365s Now, the question is, is the test incorrect (in which case, apply the |
Althought, to be fair, I have no idea why
doesn't break Lines 63 to 109 in 5bc3a8a
|
Oh, it does. The diff --git a/mage/main_test.go b/mage/main_test.go
index 286557e..4110c34 100644
--- a/mage/main_test.go
+++ b/mage/main_test.go
@@ -61,7 +61,7 @@ func testmain(m *testing.M) int {
}
func TestTransitiveDepCache(t *testing.T) {
- cache, err := internal.OutputDebug("go", "env", "gocache")
+ cache, err := internal.OutputDebug("go", "env", "GOCACHE")
if err != nil {
t.Fatal(err)
} λ @(@(7..12) | ForEach-Object { "1.$_" }) + "master" | foreach-object { "Testing golang $_"; docker run -it --rm -v "$(pwd):/go/src/github.com/magefile/mage" -w /go/src/github.com/magefile/mage "golang:$_" go test -v -run TestTransitiveDepCache ./mage/... }
Testing golang 1.7
=== RUN TestTransitiveDepCache
--- SKIP: TestTransitiveDepCache (0.07s)
main_test.go:69: skipping gocache tests on go version without cache
PASS
ok github.com/magefile/mage/mage 0.080s
Testing golang 1.8
=== RUN TestTransitiveDepCache
--- SKIP: TestTransitiveDepCache (0.04s)
main_test.go:69: skipping gocache tests on go version without cache
PASS
ok github.com/magefile/mage/mage 0.058s
Testing golang 1.9
=== RUN TestTransitiveDepCache
--- SKIP: TestTransitiveDepCache (0.03s)
main_test.go:69: skipping gocache tests on go version without cache
PASS
ok github.com/magefile/mage/mage 0.046s
Testing golang 1.10
=== RUN TestTransitiveDepCache
--- PASS: TestTransitiveDepCache (0.62s)
PASS
ok github.com/magefile/mage/mage 0.639s
Testing golang 1.11
=== RUN TestTransitiveDepCache
--- PASS: TestTransitiveDepCache (0.70s)
PASS
ok github.com/magefile/mage/mage 0.710s
Testing golang 1.12
=== RUN TestTransitiveDepCache
--- PASS: TestTransitiveDepCache (0.72s)
PASS
ok github.com/magefile/mage/mage 0.732s
Testing golang master
=== RUN TestTransitiveDepCache
--- FAIL: TestTransitiveDepCache (0.05s)
main_test.go:82: got code 1, err: Error determining list of magefiles: failed to list mage gofiles: exit status 1
FAIL
FAIL github.com/magefile/mage/mage 0.063s
FAIL Making that import absolute instead of relative also fixes that test (after fixing the casing of |
Ok, so this should be fixed with current master of mage. They dropped support for relative imports with modules. That .... seems like a go1 incompatibility, but I'm not the boss of them, so 🤷♂️ |
Great, thanks. To be fair, their spec says "To avoid ambiguity, Go programs cannot use relative import paths within a work space", and with modules every directory is "within a work space". |
Hello.
Running
go test ./...
on macOS, commit 5dee1ad gives the following:The text was updated successfully, but these errors were encountered: