go-licenses icon indicating copy to clipboard operation
go-licenses copied to clipboard

Flags stdilb as "does not have module info" when on `go 1.21.X`

Open iwahbe opened this issue 2 years ago • 6 comments

I am seeing a license warning for all stdlib packages used:

E1109 22:04:50.876016    3561 library.go:159] Package embed does not have module info. Non go modules projects are no longer supported. For feedback, refer to https://github.com/google/go-licenses/issues/128.
E1109 22:04:50.876101    3561 library.go:159] Package fmt does not have module info. Non go modules projects are no longer supported. For feedback, refer to https://github.com/google/go-licenses/issues/128.
E1109 22:04:50.876123    3561 library.go:159] Package bytes does not have module info. Non go modules projects are no longer supported. For feedback, refer to https://github.com/google/go-licenses/issues/128.
...

(source: https://github.com/pulumi/pulumi-vault/actions/runs/6817936124/job/18542508655?pr=330)

This is not the case when I change the version back from go 1.21.3 to go 1.21.


It looks like there is some problem with https://github.com/google/go-licenses/tree/master/internal/third_party/pkgsite, but I'm not familiar enough with this repo to be sure.

iwahbe avatar Nov 09 '23 22:11 iwahbe

This should be fixed in go 1.21.4

upodroid avatar Nov 29 '23 09:11 upodroid

This happened to me on go 1.12.5...

Package os/user does not have module info. Non go modules projects are no longer supported. For feedback, refer to https://github.com/google/go-licenses/issues/128.

and many others. Am I doing something wrong?

karelbilek avatar Dec 18 '23 23:12 karelbilek

The problem is that in library.go, the isStdlib() function checks whether a package is stored below GOROOT or not, and if so, it is considered to be a standard library which is allowed to have no module info. That is not true anymore when using toolchains, e.g. for me while my GOROOT is /opt/homebrew/Cellar/go/1.21.4/libexec/, the package for a standard library is coming from /Users/roland/Development/go/workspace/pkg/mod/golang.org/[email protected]/src/encoding/json/decode.go, a directory outside of GOROOT.

The result is that your standard libs (that don't have any modules) will then trigger this error because they are not detected as standard libs anymore.

// isStdLib returns true if this package is part of the Go standard library.
func isStdLib(pkg *packages.Package) bool {
	if pkg.Name == "unsafe" {
		// Special case unsafe stdlib, because it does not contain go files.
		return true
	}
	if len(pkg.GoFiles) == 0 {
		return false
	}
	prefix := build.Default.GOROOT
	sep := string(filepath.Separator)
	if !strings.HasSuffix(prefix, sep) {
		prefix += sep
	}
	return strings.HasPrefix(pkg.GoFiles[0], prefix)
}

rhuss avatar Jan 10 '24 15:01 rhuss

The solution would be to fix isStdLib() to respect toolchains to be stored outside of GOROOT.

rhuss avatar Jan 10 '24 15:01 rhuss

Some additional context:

  • The issue only hits you if you are using another toolchain than the one bundled without your go installation.
  • You can always force to use the bundled toolchain by using GOTOOLCHAIN=local as an environment variable.
  • However, when specifying a newer toolchain than your installation (either via env or go.mod), then go will download that toolchain below $GOPATH, not $GOROOT.

rhuss avatar Jan 10 '24 16:01 rhuss

You could add a toolchain default to your go.mod file.

In the end, it's a lottery ;-) If your local go installation is the same or newer than any specified toolchain (either in go.mod or via env var), then you are lucky because your bundled toolchain is used. If not, the toolchain will be downloaded by your go installation and stored below $GOPATH, not $GOROOT (probably because you might not have permission to do so).

All the gory details about toolchains are in the go toolchain docs

rhuss avatar Jan 10 '24 16:01 rhuss