ginkgo generate fails in module

[mokiat]

It seems that running ginkgo generate inside a go module, as per go 1.11, somewhere outside GOPATH results in a broken test skeleton.

Example:

package something_test

import (
	. "github.com/onsi/ginkgo"
	. "github.com/onsi/gomega"

	. "UNKNOWN_PACKAGE_PATH"
)

var _ = Describe("Something", func() {

})

The problem likely stems from the usage of ImportDir which does not work with go modules:

ginkgo/ginkgo/bootstrap_command.go

Line 106 in 000d317

pkg, err := build.ImportDir(path, 0)

This has been described here:
golang/go#26504

A workaround is to use the golang.org/x/tools/go/packages package, however it is not stable yet.

[blgm]

I’ve had that happen too. As you point out, we are in a tricky situation because people expect Gomega to work with Go modules, but Go modules (and their support packages) are not completely stable yet. I’ve heard several reports of issues with Go 1.11. I expect the stability will improve rapidly. If you (or anyone else) fancy submitting a PR that maintains backwards compatibility, then I’d gladly review it

[BrandonZacharie]

In the meantime, you can symlink your project and run ginkgo generate from there.

• mkdir -p $GOPATH/src/github.com/_my_account_/_my_project_/
• cd $GOPATH/src/github.com/_my_account_/
• ln -s _path_to_my_project_
• cd _path_to_my_project_/_path_to_package_
• ginkgo generate _some_file_

EDIT: This suggestion is targeted for macOS users; adapt as necessary.

[mokiat]

@blgm , as you mentioned, their new modules support packages (namely golang.org/x/tools/go/packages) are still not stable. According to the linked issue, the go/build package should shell out to the go executable as a quick workaround, however, that did not work for a tool of mine (whereas go/packages did).

On the plus side, the ginkgo tool does not crash and handles this in a somewhat graceful way. There is always the workaround proposed by @BrandonZacharie .

That said, I would advise against half-baked workaround solutions for now, and instead wait for go/packages to become a stable package or for alternative (stable) solutions. Still, considering the ever-increasing number of packages that are migrated to go modules, I would keep this issue open as a reminder.

[leninhasda]

Can we use this as a solution?

// ModulePath returns the module path from the gomod file text.
// If it cannot find a module path, it returns an empty string.
// It is tolerant of unrelated problems in the go.mod file.
func ModulePath(mod []byte) string {
	for len(mod) > 0 {
		line := mod
...

https://github.com/golang/go/blob/master/src/cmd/go/internal/modfile/read.go#L837

I mean, this is how go internally read the module path from go.mod file. And maybe it's a good idea to copy a function instead of pulling a package!
Or is there something else I might be missing and need to look into?