google / go-licenses

A lightweight tool to report on the licenses used by a Go package and its dependencies. Highlight! Versioned external URL to licenses can be found at the same time.
Apache License 2.0
790 stars 117 forks source link

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

Open iwahbe opened 7 months ago

iwahbe commented 7 months ago

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.

upodroid commented 7 months ago

This should be fixed in go 1.21.4

karelbilek commented 6 months ago

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?

rhuss commented 5 months ago

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/toolchain@v0.0.1-go1.21.5.darwin-arm64/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 commented 5 months ago

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

rhuss commented 5 months ago

Some additional context:

rhuss commented 5 months ago

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