io.ReadAll undefined error

[amit-thakur-S]

We have recently updated to gomega v1.17.0 and are getting the below error:

#14 40.36 /go/pkg/mod/github.com/onsi/[email protected]/matchers/have_http_body_matcher.go:84:30: undefined: io.ReadAll
#14 40.36 /go/pkg/mod/github.com/onsi/[email protected]/matchers/have_http_status_matcher.go:81:16: undefined: io.ReadAll
#14 40.36 note: module requires Go 1.16

Our go.mod file contains

github.com/onsi/ginkgo v1.16.4
github.com/onsi/gomega v1.17.0

We are using GO version to 1.16.6. Please suggest a fix for this.

[onsi]

Are you sure 1.16.6 is the version of go being invoked here and not accidentally some other version? Gomega 1.17.0 does work with go 1.16.x which has io.ReadAll i the stdlib.

[scottillogical]

I'm getting this on go 1.15.4, works on v1.16.0

[Woody1193]

I'm also getting this on my CI/CD which runs go 1.13.15. The issue started this morning.

[Woody1193]

Update:

Downgrading gomega to v1.16.0 fixed this issue so the issue is entirely related to v1.17.0.

[onsi]

Just to clarify - this isn't an issue in Gomega. Go 1.16.0 deprecated ioutil in favor of new methods in the io and os packages. Gomega 1.17.0 simply starts using those new methods - note that the go.mod for 1.17.0 stipulates a minimum go version of 1.16 - if you need to use an older version of go you'll need to use an older version of Gomega.

[nodece]

Root cause: The #467 breaks this.

I note that the ioutil doesn't mark with a Deprecated, and if we should gomega 1.17.0, we have to upgrade our golang, it is complex, do we consider continuing the use of the ioutil?

[onsi]

hey @nodece - Go's formal support policy is the two latest minor releases - and Gomega's support policy is for the latest version to work with the supported versions of Go. So, Gomega 1.17.0 works on both Go 1.16 and 1.17.

Pragmatically speaking it would be straightforward to revert #467 - and I can do that and am willing to do that. But perhaps this is an opportunity for a conversation first. It seems the long-term sustainable path here is for projects that consume Go to do the work to stay on supported versions of Go. I know that work isn't easy - far from it. But it is the reality of building production software on top of Go.

Libraries like Ginkgo and Gomega are OSS projects made available - and supported - for free. As such they need to have a sustainable support policy and that is the one that is currently in place. While this particular case is relatively trivial to fix there will undoubtedly be future versions of Ginkgo/Gomega that will have dependencies on future versions of Go that will not be trivial to backport support for older versions of Go.

So. I can revert #467 - but it seems to me that upgrading to a supported version of Go ought to be the higher priority for most projects than upgrading to the latest Gomega, no?

[nodece]

Thank @onsi, Gomega is an awesome library, for upgrading the Go to supported versions or using Gomega 1.16 on < Go 1.16 is a good idea, but I think if the Gomega can work on Go 1.14-1.17 will awesome, sometimes we don't want to upgrade the Golang version because of Gomega. If the Gomega 1.17 does not support the old go version just because it uses io.ReadAll, I think we should revert the #467 to works on Go 1.14 - Go 1.17, otherwise, we should add Golang requirement on our documentation, so like:

The Gomega 1.17.0 requires the Golang 1.16, if you want to use the Gomeg on Golang 1.15 or lower version, please install the Gomega 1.16.0

[onsi]

@blgm just submitted #492 which resolves this issue. I've pulled it in and will cut a new release.

[onsi]

This is now fixed on 1.18.0. That should unblock y'all .