Client-go: Lowercase openapiv2 imports
Build breaking changes due to https://github.com/googleapis/gnostic/pull/155
Need to update imports to github.com/googleapis/gnostic/openapiv2
Here is the error:
go get k8s.io/client-go/kubernetes
---> Running in 2aec6896da7e
package github.com/googleapis/gnostic/OpenAPIv2: cannot find package "github.com/googleapis/gnostic/OpenAPIv2"
mganta
All 20 comments
Getting a specific version will make use of correct transitive versions. For example, go get k8s.io/[email protected]
See the INSTALL.md in the repo root for details
liggitt
on 1 Feb 2020
Getting a specific version will make use of correct transitive versions. For example,
go get k8s.io/[email protected]See the INSTALL.md in the repo root for details
failed again and correct solution is to use a special version of github.com/googleapis/gnostic,such as v0.3.1
TUTUBIG
on 19 Mar 2020
Getting a specific version will make use of correct transitive versions. For example,
go get k8s.io/[email protected]
This does not work.
$ go get k8s.io/[email protected] ./...
go: finding module for package github.com/googleapis/gnostic/OpenAPIv2
go: finding module for package github.com/googleapis/gnostic/OpenAPIv2
../../go/pkg/mod/k8s.io/[email protected]/discovery/discovery_client.go:29:2: module github.com/googleapis/gnostic@latest found (v0.4.1), but does not contain package github.com/googleapis/gnostic/OpenAPIv2
nyetwurk
on 24 Mar 2020
try go get k8s.io/[email protected] alone
to see what else in your build is requiring a newer version of github.com/googleapis/gnostic, run:
go mod graph | grep github.com/googleapis/gnostic
Had to do both at the same time
go get -u k8s.io/[email protected] github.com/googleapis/[email protected] ./...
since another module depends on gnostic.
When will upstream be fixed?
nyetwurk
on 24 Mar 2020
Same issue here. This is breaking my whole testing suite.
kubilesti
on 26 Mar 2020
Please update at least one of the semver client-go versions i can reference (not master), TIA :)
nyetwurk
on 31 Mar 2020
Existing client-go versions will not be updated. Updating this dependency is being looked at in https://github.com/kubernetes/kubernetes/pull/89704 and https://github.com/kubernetes/kube-openapi/pull/189, targeting Kubernetes 1.19.
liggitt
on 31 Mar 2020
Had to do both at the same time
go get -u k8s.io/[email protected] github.com/googleapis/[email protected] ./...since another module depends on gnostic.
When will upstream be fixed?
Thank you so much
vishutrilio
on 20 Sep 2020
Had to do both at the same time
go get -u k8s.io/[email protected] github.com/googleapis/[email protected] ./...since another module depends on gnostic.
When will upstream be fixed?
Same issue here but only happens on ubuntu. On windows github.com/googleapis/[email protected] is fine.
InfluencerNGZK
on 24 Sep 2020
A recap for those seeing an issue with the casing of github.com/googleapis/gnostic/openapiv2: Older versions of the openapiv2 package had a mixed-case name, then was updated to be lower-case. Pre-1.19 builds of K8s used the former, and now use the latter. You might experience a problem if you're building on a case-sensitive filesystem, esp. if using go mod vendoring. Possible fix is to git remove the vendored content and then re-sync.
EronWright
on 10 Nov 2020
You might experience a problem if you're building on a case-sensitive filesystem
This should be reworded as
"You will experience problems unless you're building on a case-insensitive filesystem". The latter is the exception, not the rule. Relying on case insensitivity is a bug. There is zero reason pre-1.19 k8s shouldn't be fixed; they're in active use throughout the community. Disagree strongly with closing this bug. 1.17 and 1.18 are still very much (again) the rule, not the exception.
go mod vendor/go mod tidy/rm -rf vendor do not solve the underlying problem which is that pre 1.19 you have to pin random versions of things to get them to build.
nyetwurk
on 11 Nov 2020
Always specify matching versions of all three k8s.io/... components in your go.mod file
require (
...
k8s.io/api v0.19.0
k8s.io/apimachinery v0.19.0
k8s.io/client-go v0.19.0
...
)
from: https://stackoverflow.com/questions/63655419/kubernetes-client-go-couldnt-find-module
this solved my problem, which wasted my several hours.
aslin3
on 2 Dec 2020
Getting a specific version will make use of correct transitive versions. For example,
go get k8s.io/[email protected]See the INSTALL.md in the repo root for details
This is the last comment before the bug was unceremoniously closed, and it is inaccurate.
nyetwurk
on 2 Dec 2020
@liggitt Any chance we can get this re-opened?
This bug is seriously annoying, and I'm not fond of just randomly pinning versions until it works.
Downgrading to pre-0.19 isn't really a good option either for those of us that want to keep their dependencies updated.
For everybody else who's still struggling with this issue, the easiest way to go about "fixing" this issue for now is to use a pre-0.19 version of client-go. At the time of this message, the latest one is v0.18.14, which means your go.mod should look like this:
require (
// ...
k8s.io/api v0.18.14
k8s.io/apimachinery v0.18.14
k8s.io/client-go v0.18.14
)
replace k8s.io/client-go => k8s.io/client-go v0.18.14
TwinProduction
on 25 Dec 2020
Agreed, it's inexcusable at this point
nyetwurk
on 25 Dec 2020
The v0.19.x and v0.20.x versions of client-go work with the latest lowercased openapi library, so no pinning is required with those versions.
liggitt
on 25 Dec 2020
@liggitt I think the issue for many is that a lot of projects and deployments depend on pre-v0.19.x versions of this package, and updating to post-v0.19.x requires lots of changes to function signatures. If I sat down over New Years and fixed the broken imports from version v0.16.x to v0.18.x and put out PRs, would you merge them?
JPZ13
on 30 Dec 2020
@liggitt I think the issue for many is that a lot of projects and deployments depend on pre-v0.19.x versions of this package, and updating to post-v0.19.x requires lots of changes to function signatures.
client-go 0.16.x-0.18.x versions work as-is if you use the matching version of the openapi library and don't have other dependencies that require the lowercase openapi packages. if you need/want to use the latest openapi version after the package name break, upgrading to client-go 0.19.x+ is the way to do that.
If I sat down over New Years and fixed the broken imports from version v0.16.x to v0.18.x and put out PRs, would you merge them?
No, backporting an incompatible dependency change to a patch release would be just as likely to break existing client-go consumers who have some other dependency in their tree that uses the uppercase openapi packages. We limit that sort of change to Kubernetes minor versions.
liggitt
on 30 Dec 2020
Makes sense. Thanks, man
JPZ13
on 30 Dec 2020
Related issues
AdheipSingh
路
5Comments
peterwillcn
路
5Comments
alexec
路
5Comments
protheusfr
路
3Comments
tamalsaha
路
6Comments
Most helpful comment
This should be reworded as
"You will experience problems unless you're building on a case-insensitive filesystem". The latter is the exception, not the rule. Relying on case insensitivity is a bug. There is zero reason pre-1.19 k8s shouldn't be fixed; they're in active use throughout the community. Disagree strongly with closing this bug. 1.17 and 1.18 are still very much (again) the rule, not the exception.
go mod vendor/go mod tidy/rm -rf vendordo not solve the underlying problem which is that pre 1.19 you have to pin random versions of things to get them to build.