Cannot use GetOptions{}?

[rubenv]

I'm having code like this:

_, err = nsClient.Get(t.namespace, meta_v1.GetOptions{})

Where nsClient is a v1.NamespaceInterface.

This defines the Get() method as follows:

Get(name string, options meta_v1.GetOptions) (*v1.Namespace, error)

Sadly meta_v1 is a vendored package:

meta_v1 "k8s.io/apimachinery/pkg/apis/meta/v1"

If I refer to GetOptions() in my code directly, by adding the same import, I get the following:

./targets.go:138: cannot use "k8s.io/apimachinery/pkg/apis/meta/v1".GetOptions
 literal (type "k8s.io/apimachinery/pkg/apis/meta/v1".GetOptions) as type
 "k8s.io/client-go/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".GetOptions
 in argument to nsClient.Get

Whereas when I try to refer to the vendored package, I get the (correct) error:

package github.com/rubenv/kube-appdeploy
        imports k8s.io/client-go/vendor/k8s.io/apimachinery/pkg/apis/meta/v1:
        use of vendored package not allowed

How on earth is one supposed to use this library?

[lavalamp]

Check out this section of the readme: https://github.com/kubernetes/client-go#dependency-management

Unfortunately this is just the way go works. If we didn't ship with the vendor folder, then you wouldn't have this problem--but you also would have no way of getting a set of dependencies that we believe works together.

[rubenv]

So am I right in my understanding that there's no way to use this library with plain go get?

That's a massive bummer :-(

[lavalamp]

I spoke a little too soon, it does seem like we shouldn't do this to people with our own packages. The meta/v1 package is pretty new, we're in the process of moving various pieces to places that make more sense. We're also vendoring the apimachinery repo because we're not to the point where we want to version it--we expect it to change rapidly for a bit and we don't want to break client-go users. Maybe @deads2k or @smarterclayton have an idea about how to make this better in the short term?

…

On Tue, Jan 17, 2017 at 11:01 AM, Ruben Vermeersch ***@***.*** > wrote: So am I right in my understanding that there's no way to use this library with plain go get? That's a massive bummer :-( — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnglqkHAkRQEhN48pCD55RBZJSGEc32ks5rTRACgaJpZM4LkbAn> .

[lavalamp]

You may want to go back to the previous alpha tag until we figure this out.

[deads2k]

I spoke a little too soon, it does seem like we shouldn't do this to people
with our own packages. The meta/v1 package is pretty new, we're in the
process of moving various pieces to places that make more sense. We're also
vendoring the apimachinery repo because we're not to the point where we
want to version it--we expect it to change rapidly for a bit and we don't
want to break client-go users.

Maybe @deads2k or @smarterclayton have an idea about how to make this
better in the short term?

Matching dependency levels is just the way that the native go vendoring system works. go get assumes that every library everywhere operates correctly on head, it's how they build their default tools. It's frustrating and that's exactly why the different vendoring tools have propagated around the language.

You really can't avoid it, even with your own packages, if you want to have different libraries that work together. For example, apimachinery, client-go, apiserver. It's very reasonable for someone to need all three. If you make copies, then the types won't match (go won't recognize second order interfaces which are equivalent) and it becomes impossible for any project (k8s.io/kubernetes, service-catalog, openshift, as examples), to rely on both client-go and apiserver no matter how they vendor.

[lavalamp]

Actually, you may want to stick with the v1.5 tag until we sort this out. Like the top-level README says, go get gives you unstable head. go's dependency management system is making it really hard for us to serve every use case, unfortunately.

[rubenv]

Actually, you may want to stick with the v1.5 tag until we sort this out. Like the top-level README says, go get gives you unstable head.

I'm fine with that to be honest. As it stands it's simply impossible to use go get. I'm really hoping the final solution won't be "use vendoring tools" and give up on go get.

[emaildanwilson]

I just hit this as well.... I was really hoping that the client-go library would not have dependancies like this that forced the use of godeps. It's still better than getting the whole kubernetes project :)

[lavalamp]

My current plan is to get the client to start using https://github.com/golang/dep for dep management, but I'm shorthanded and it is going to take a while to get this to happen.

…

On Tue, Jan 24, 2017 at 1:50 PM, Dan Wilson ***@***.***> wrote: I just hit this as well.... I was really hoping that the client-go library would not have dependancies like this that forced the use of godeps. It's still better than getting the whole kubernetes project :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAngljyXuWPVY9BMhGBGIJyyie1gOufCks5rVnIqgaJpZM4LkbAn> .

[ianrose14]

+1 to anything that can improve the first-time, out of the box experience. Fighting with a bunch of dependencies before you can get anything to run is a real headache.

[emaildanwilson]

I was able to use dep locally in my own project to easily use the client and lock versions.

go get github.com/golang/dep

#from my project that uses client-go
dep ensure github.com/golang/glog@44145f04b68cf362d9c4df2182967c2275eaefed
dep ensure k8s.io/client-go@release-1.5
dep ensure -update

[lavalamp]

Great to hear, thanks!

…

On Thu, Jan 26, 2017 at 3:31 PM, Dan Wilson ***@***.***> wrote: I was able to use dep locally in my own project to easily use the client and lock versions. go get github.com/golang/dep #from my project that uses client-go dep ensure ***@***.*** dep ensure ***@***.*** dep ensure -update — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAngloUr9AXQN4hzbbwEI4davR3kld0Lks5rWSzYgaJpZM4LkbAn> .

[rubenv]

This by the way is the same issue as #83

[lavalamp]

Please use the v2.0.0 tag. I believe we have addressed most of the concerns raised here, please take a look at the current README.