Skip to content
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

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

Open
iwahbe opened this issue Nov 9, 2023 · 6 comments · May be fixed by pulumi/go-licenses#1
Open

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

iwahbe opened this issue Nov 9, 2023 · 6 comments · May be fixed by pulumi/go-licenses#1

Comments

@iwahbe
Copy link

iwahbe commented Nov 9, 2023

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 iwahbe changed the title Flags stdilb on when go 1.21.X Flags stdilb as "does not have module info" when on go 1.21.X Nov 9, 2023
@kmosher kmosher linked a pull request Nov 9, 2023 that will close this issue
@upodroid
Copy link

This should be fixed in go 1.21.4

@karelbilek
Copy link

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
Copy link

rhuss commented Jan 10, 2024

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
Copy link

rhuss commented Jan 10, 2024

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

@rhuss
Copy link

rhuss commented Jan 10, 2024

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
Copy link

rhuss commented Jan 10, 2024

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

iwahbe added a commit to pulumi/license-check-action that referenced this issue Feb 19, 2024
This is a workaround for google/go-licenses#244.
iwahbe added a commit to pulumi/license-check-action that referenced this issue Feb 20, 2024
* Ignore stdlib

This is a workaround for google/go-licenses#244.

* Add an explanatory comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants