Update k8s.io/client-go to a valid version

[stevehipwell]

The current import of k8s.io/client-go v11.0.0+incompatible causes any project inheriting from this to loose their correct k8s.io/client-go import. Could you pick a version from K8s v1.17 upwards (v0.x.y) and use that library version (e.g. k8s.io/client-go v0.18.15 for K8s v1.18).

If you have a dependency forcing you to k8s.io/client-go v11.0.0+incompatible please could you use the following pattern to fix projects consuming this project.

// Pin kubernetes dependencies to 1.18.15
replace (
	k8s.io/api => k8s.io/api v0.18.15
	k8s.io/apimachinery => k8s.io/apimachinery v0.18.15
	k8s.io/client-go => k8s.io/client-go v0.18.15
)

require (
	k8s.io/client-go v11.0.0+incompatible
)

[hairyhenderson]

Hi @stevehipwell, thanks for logging this.

I'll have a look at this, there shouldn't be a problem with grabbing the latest proper version.

There's some background linked from here too: #629

Ultimately I'm not super happy that I need to pull in k8s.io/client-go just for jsonpath - it seems like that should be in a separate module. I may do something about that at some point... 🤔

[stevehipwell]

@hairyhenderson would you like a PR? If so I'd suggest maybe v0.17.17 which is the latest version for K8s v1.17 release and they made fairly major changes in the libs for K8s v1.18.

[hairyhenderson]

I'd love a PR!

I only use the util/jsonpath package, which looks to be unchanged (except for bug fixes) between v0.17.17 and v0.20.2 - why shouldn't I go with the latest?

[stevehipwell]

I think you could go with any version from 0.15 onwards, but the significant changes to method signatures happened in the v0.18 release which is why I'm suggesting v0.17 as a good compromise (I've looked at a number of packages that have a K8s dependency and v0.17 seems well represented.

[hairyhenderson]

but the significant changes to method signatures happened in the v0.18 release

No changes happened in v0.18 to methods that gomplate is referencing... So v0.20.2 is fine.

[stevehipwell]

I was referring to methods that consumers might be using, in my case I need to stick with v0.17.17 due to another dependency I'm using.

[hairyhenderson]

@stevehipwell oh - does that mean gomplate using v0.20.2 won't work for you?

[stevehipwell]

@hairyhenderson I'm not sure, which is why I was proposing a v0.17 release even if you then bumped up to v0.20 on the next release.

[hairyhenderson]

@stevehipwell why don't you try with the specific commit in #1063 now, to validate whether it'll work?

Just do go get -u github.com/hairyhenderson/gomplate/v3@ce48a0a to update your go.mod to the commit.

[stevehipwell]

@hairyhenderson I'm done for the day but will give it a try first thing in the morning (I'm in the UK).

[stevehipwell]

@hairyhenderson I can use it with a replace block and it's better than the v11.0.0+incompatible so it's a thumbs up from me.

[hairyhenderson]

Ok, thanks @stevehipwell!