Import paths aren't support with go modules

[poy]

I tried the following while in a repo with go modules enabled:

ko publish github.com/foo/bar/cmd/bar

However I got the following error:

2020/02/05 13:44:28 failed to publish images: importpath "github.com/foo/bar/cmd/bar" is not supported

I can work around it by doing:

GO111MODULE=off ko publish github.com/foo/bar/cmd/bar

However, this is not intuitive and it does not respect the given version found in my go.mod file.

[jonjohnsonjr]

This works for me:

~/go/src/github.com/google/ko $ ko publish github.com/google/ko/cmd/ko
2020/02/05 12:50:30 Using base gcr.io/distroless/static:latest for github.com/google/ko/cmd/ko
2020/02/05 12:50:31 Building github.com/google/ko/cmd/ko
2020/02/05 12:50:41 Publishing gcr.io/jonjohnson-test/ko/ko-099ba5bcefdead87f92606265fb99ac0:latest
2020/02/05 12:50:44 Published gcr.io/jonjohnson-test/ko/ko-099ba5bcefdead87f92606265fb99ac0@sha256:63956909652a580a46264674ecb8bec8ed64e0c2e7aca2c547920001cef6a12d
gcr.io/jonjohnson-test/ko/ko-099ba5bcefdead87f92606265fb99ac0@sha256:63956909652a580a46264674ecb8bec8ed64e0c2e7aca2c547920001cef6a12d

There are some caveats though. With go modules, we don't have a global root for searching for modules anymore, so we first check to see if we're in a go modules project via:

$ go list -mod=readonly -m -json

Then we check to see if the path matches what's in your go.mod file here with a simple prefix heuristic.

That generally works, but you might be hitting #106

[poy]

Does your example only work then because you are building ko from the ko repo?

[jonjohnsonjr]

Yes -- if your current working directory is using go modules, we use the go.mod file essentially as your go root. Building a different project used to work because we could assume any package was at a specific place on your GOPATH. With modules, we can't rely on that.

I think my initial PR would fall back to GOPATH to look for a package, but we decided that would be confusing: #60 (comment)

If you have a reasonable use case for it, I'm not opposed to it. When we implemented support for go modules, we weren't really sure how people were using modules with multiple repos.

[poy]

I think my expectation was similar to when I use the go tool. Every command (e.g., test, build), downloads the necessary packages listed in go.mod file. I suppose it would also need to be able to utilize the vendor directory.

[jonjohnsonjr]

This seems like something we could support in strict mode where we know a given string represents a go package, but without it this would probably be too expensive.

ko publish arguments are also a strong enough signal we could assume they're packages and do the right thing here.

[jonjohnsonjr]

I pushed the simplest thing I could imagine to try to fix this, but I haven't tested it extensively... want to give #139 a try?

[poy]

Hm, it didn't seem to help.

I'm still getting the same error.

[jonjohnsonjr]

I think I'm mixing three related but not quite exactly the same issues...

I just pushed bc8f117 which would fix your issue with ko publish (I think), but wouldn't work if you try to ko apply something that references a repo not on your GOPATH. Doing that would be a bit more work, but would you expect it to work?

[poy]

It seems to get further however I still get an error:

$ cat go.mod
module github.com/x/x

go 1.14

require github.com/google/ko v0.4.0 // indirect

$ ko publish github.com/google/ko/cmd/ko
2020/03/11 22:41:24 Using base gcr.io/distroless/static:latest for github.com/google/ko/cmd/ko
2020/03/11 22:41:27 Building github.com/google/ko/cmd/ko
2020/03/11 22:41:42 failed to publish images: error building "github.com/google/ko/cmd/ko": unmatched importPackage with gomodules

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.