Re: [go-nuts] multiple vendor path for same type

[Ian Lance Taylor]

On Fri, May 15, 2020 at 10:04 AM Nobin Mathew  wrote:
>
> I am almost new to golang, sorry if I am asking some silly question.
>
> I am facing some compilation issue due to type conflict
>
> **
>
> +++ [0515 07:51:26] Building go targets for linux/amd64:
> test/e2e/e2e.test
> # k8s.io/kubernetes/test/e2e/framework
> test/e2e/framework/framework.go:239:44: cannot use config (type 
> *"k8s.io/kubernetes/vendor/k8s.io/client-go/rest".Config) as type 
> *"k8s.io/kubernetes/vendor/github.com/k8snetworkplumbingwg/network-attachment-definition-client/vendor/k8s.io/client-go/rest".Config
>  in argument to 
> "k8s.io/kubernetes/vendor/github.com/k8snetworkplumbingwg/network-attachment-definition-client/pkg/client/clientset/versioned/typed/k8s.cni.cncf.io/v1".NewForConfig
> test/e2e/framework/framework_multus.go:14:3: cannot use 
> "k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta 
> literal (type 
> "k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta) 
> as type 
> "k8s.io/kubernetes/vendor/github.com/k8snetworkplumbingwg/network-attachment-definition-client/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta
>  in field value
> !!! [0515 07:51:30] Call tree:
> !!! [0515 07:51:30]  1: 
> /home/eccd/go/src/k8s.io/kubernetes/hack/lib/golang.sh:853 
> kube::golang::build_binaries_for_platform(...)
> !!! [0515 07:51:30]  2: hack/make-rules/build.sh:27 
> kube::golang::build_binaries(...)
> !!! [0515 07:51:30] Call tree:
> !!! [0515 07:51:30]  1: hack/make-rules/build.sh:27 
> kube::golang::build_binaries(...)
> !!! [0515 07:51:30] Call tree:
> !!! [0515 07:51:30]  1: hack/make-rules/build.sh:27 
> kube::golang::build_binaries(...)
> make: *** [Makefile:93: all] Error 1
>
> ***
>
> I Included a library
>
> "github.com/k8snetworkplumbingwg/network-attachment-definition-client/pkg/client/clientset/versioned/typed/k8s.cni.cncf.io/v1"
>
> in kubernetes (this is for some internal development, kubernetes guys wont 
> like it :) )
>
>
>
> if you look at line number 239:44 error, there is type conflict but it is 
> actually pointing to same struct.
> Expecting is
> "k8s.io/kubernetes/vendor/github.com/k8snetworkplumbingwg/network-attachment-definition-client/vendor/k8s.io/client-go/rest".Config"
>
> but provided "k8s.io/kubernetes/vendor/k8s.io/client-go/rest".Config"
>
> But if you look at what is after "vendor", both are same i.e. 
> "k8s.io/client-go/rest".Config"
>
>
>
> How can I solve this problem. I any help or pointers will be helpful(any 
> directions to read).

In Go, types are distinguished by the import path used to find the type.

In this case, it looks like you have the same package at two different
positions in your source tree.  Go will treat the types defined in
those two different packages as different types.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV%3DZ5ddVWH9ci3txv-pR6ffApsdOv9%3DZg_wGPbrrzDQ8g%40mail.gmail.com.

Re: [go-nuts] randomly go loading modules fail

[Tyler Compton]

I saw some discussion in a previous thread indicating that Gitlab is having
an incident. More details here:
https://status.gitlab.com/pages/history/5b36dc6502d06804c08349f7

On Fri, May 15, 2020 at 10:04 AM msherif4 via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Hi :
>
>  I have seen randomly go dependancies fail to load certain modules
> like the case below
>
> [0m [91mgo: modernc.org/mathutil@v1.0.0: git fetch -f origin 
> refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in 
> /go/pkg/mod/cache/vcs/fb72eb2422fda47ac75ca695d44b06b82f3df3c5308e271486fca5e320879130:
>  exit status 128:
>   fatal: unable to access 'https://gitlab.com/cznic/mathutil/': The 
> requested URL returned error: 502
>
>
> [0m [91mgo: modernc.org/xc@v1.0.0: git fetch -f origin 
> refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in 
> /go/pkg/mod/cache/vcs/29fc2f846f24ce3630fdd4abfc664927c4ad22f98a3589050facafa0991faada:
>  exit status 128:
>   fatal: unable to access 'https://gitlab.com/cznic/xc/': The requested 
> URL returned error: 502
> go: error loading module requirements
>
>
> again this happens randomly not consistent
>
>
> anyone run into the same and is there anyway to fix it ?
>
>
> Thanks!!
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5e12cce1-dcee-4276-97af-daf4bec9e111%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3sfkRUkCnvw84vb-FXU%2BupRBDsEmcQzJnLuoWBNfd8-Q%40mail.gmail.com.

[go-nuts] multiple vendor path for same type

[Nobin Mathew]

Hi all,

I am almost new to golang, sorry if I am asking some silly question. 

I am facing some compilation issue due to type conflict

**

+++ [0515 07:51:26] Building go targets for linux/amd64:
test/e2e/e2e.test
# k8s.io/kubernetes/test/e2e/framework
test/e2e/framework/framework.go:239:44: cannot use config (type 
*"k8s.io/kubernetes/vendor/k8s.io/client-go/rest".Config) as type 
*"k8s.io/kubernetes/vendor/github.com/k8snetworkplumbingwg/network-attachment-definition-client/vendor/k8s.io/client-go/rest".Config
 
in argument to 
"k8s.io/kubernetes/vendor/github.com/k8snetworkplumbingwg/network-attachment-definition-client/pkg/client/clientset/versioned/typed/k8s.cni.cncf.io/v1".NewForConfig
test/e2e/framework/framework_multus.go:14:3: cannot use 
"k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta 
literal (type 
"k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta) 
as type 
"k8s.io/kubernetes/vendor/github.com/k8snetworkplumbingwg/network-attachment-definition-client/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta
 
in field value
!!! [0515 07:51:30] Call tree:
!!! [0515 07:51:30]  1: 
/home/eccd/go/src/k8s.io/kubernetes/hack/lib/golang.sh:853 
kube::golang::build_binaries_for_platform(...)
!!! [0515 07:51:30]  2: hack/make-rules/build.sh:27 
kube::golang::build_binaries(...)
!!! [0515 07:51:30] Call tree:
!!! [0515 07:51:30]  1: hack/make-rules/build.sh:27 
kube::golang::build_binaries(...)
!!! [0515 07:51:30] Call tree:
!!! [0515 07:51:30]  1: hack/make-rules/build.sh:27 
kube::golang::build_binaries(...)
make: *** [Makefile:93: all] Error 1

***

I Included a library  

"github.com/k8snetworkplumbingwg/network-attachment-definition-client/pkg/client/clientset/versioned/typed/k8s.cni.cncf.io/v1"

in kubernetes (this is for some internal development, kubernetes guys wont like 
it :) )



if you look at line number 239:44 error, there is type conflict but it is 
actually pointing to same struct.
Expecting is 
"k8s.io/kubernetes/vendor/github.com/k8snetworkplumbingwg/network-attachment-definition-client/vendor/k8s.io/client-go/rest".Config"

but provided "k8s.io/kubernetes/vendor/k8s.io/client-go/rest".Config" 

But if you look at what is after "vendor", both are same i.e. 
"k8s.io/client-go/rest".Config"



How can I solve this problem. I any help or pointers will be helpful(any 
directions to read).


-Nobin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e74cec82-1bd9-45db-b373-25277f7678ac%40googlegroups.com.

[go-nuts] randomly go loading modules fail

[msherif4 via golang-nuts]

Hi :

 I have seen randomly go dependancies fail to load certain modules 
like the case below

[0m [91mgo: modernc.org/mathutil@v1.0.0: git fetch -f origin 
refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in 
/go/pkg/mod/cache/vcs/fb72eb2422fda47ac75ca695d44b06b82f3df3c5308e271486fca5e320879130:
 exit status 128:
fatal: unable to access 'https://gitlab.com/cznic/mathutil/': The 
requested URL returned error: 502


[0m [91mgo: modernc.org/xc@v1.0.0: git fetch -f origin 
refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in 
/go/pkg/mod/cache/vcs/29fc2f846f24ce3630fdd4abfc664927c4ad22f98a3589050facafa0991faada:
 exit status 128:
fatal: unable to access 'https://gitlab.com/cznic/xc/': The requested 
URL returned error: 502
go: error loading module requirements


again this happens randomly not consistent


anyone run into the same and is there anyway to fix it ?


Thanks!! 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5e12cce1-dcee-4276-97af-daf4bec9e111%40googlegroups.com.

[go-nuts] Re: How url use Html templates?

[Ali Hassan]

Thank you

On Thursday, May 14, 2020 at 9:05:29 PM UTC+5, Ali Hassan wrote:
>
>
> Html Templates
>{{if .Done}}
>  
>
>{{end}}
>
> My question is this   , possible that Url 
> have string value "/HelloQ/home/" which which show as url link option which 
> you can open if you click on that link
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/07b79bcc-003f-463a-92b5-04490a9c4af6%40googlegroups.com.

Re: [go-nuts] net/http: question about RoundTripper

[Anuj Agrawal]

Thanks Kevin for these insights. It does seem like the documentation
notes were meant for Go core devs. It would have helped, if the
authors threw in more insight.

I have also been using RoundTripper as client middleware, but so far
largely for authentication. I wanted to expand the scope of the client
middleware in my implementations to do more but looking at the
RoundTripper documentation, I wanted to have views on its use and see
if I can find anti-patterns that I should be aware of.

In fact, since I could not find a lot of useful information around it,
I even felt like writing a blog post highlighting good and bad
patterns using RoundTripper based on the notes I collect.


On Tue, May 12, 2020 at 7:38 AM Kevin Conway  wrote:
>
> I'll make an attempt to answer this question but I could be wrong given some 
> deeper historical context between the early Go developers.
>
> There are two chunks of the http.RoundTripper comments that folks typically 
> ask about: "should not attempt to handle higher-level protocol details" and 
> "should not modify the request". Unfortunately, the rationale for why these 
> statements are made is neither presented in the comments nor in the patches 
> that introduced them.
>
> It appears "should not modify the request" most likely refers to a 
> concurrency issue that must be mitigated by copying the request before 
> mutating it in the RoundTripper. Here's the change that claims to have 
> resolved an issue surrounding this: https://codereview.appspot.com/5284041. 
> The original comments explicitly allowed for mutating the request but this 
> was changed to "should not" after this patch due to the bug that it resolved.
>
> It's a little harder to find direct evident of the author's intent for 
> "should not attempt to handle higher-level protocol details". This part of 
> the comment has been in the code for nearly a decade and it becomes fairly 
> difficult to track the origin past a set of major renames and large movements 
> of files from place to place within the early Go source code. Reading 
> https://github.com/golang/go/commit/e0a2c5d4b540934e06867710fe7137661a2a39ec 
> makes it seem like these notes were meant for the author or for other Go core 
> devs who were building the original HTTP stack rather than those of us who 
> would use it later. For example, it appears to signal that standard library 
> developers should isolate higher level features within the Client type rather 
> than in the ClientTransport (now RoundTripper) type. I haven't found 
> anything, yet, that suggests the comments are meant for anyone other than 
> developers of the http package in the Go standard library.
>
> From a more practical perspective, you don't really have another choice when 
> it comes to HTTP client middleware that are generally useful in Go 
> applications than the http.RoundTripper interface. If everyone applied the 
> "accept interfaces, return structs" guidelines then you would have more 
> options. For example, if everything that needed an HTTP client accepted a 
> "type Doer { Do(r *http.Request) (*http.Response, Error) }" style interface 
> then you could target your middleware as wrappers for the http.Client. 
> Unfortunately, most projects that allow for injection of a custom HTTP client 
> do so by accepting an instance of *http.Client. Accepting that specific, 
> concrete type makes wrapping anything other than the http.RoundTripper a 
> practical impossibility.
>
> Personally, I've been using http.RoundTripper middleware for several years 
> without issue. It's a solid pattern that can provide an enormous amount of 
> value by allowing re-usable layers of behavior that can be injected into 
> virtually any library or framework that uses an HTTP client. I don't worry 
> about the comments in the standard library for the reasons I listed.
>
> On Mon, May 11, 2020 at 2:01 PM Anuj Agrawal  wrote:
>>
>> I am trying to understand in what cases would it make sense to
>> implement my own RoundTripper.
>>
>> If I search about it, I come across examples of RoundTripper that try
>> to do things like caching, retries, authentication, etc. I also read
>> somewhere that there are many RoundTripper implementations that just
>> set the User-Agent header on a request.
>>
>> I know that the documentation says "RoundTrip should not attempt to
>> handle higher-level protocol details such as redirects,
>> authentication, or cookies." And, I also understand that RoundTripper
>> would be a bad place for things like caching.
>>
>> However, I am not able to figure out why is it such a bad idea to use
>> RoundTripper as a middleware that allows me to do some of the higher
>> level things like authentication. After all, authentication is just
>> about interpreting and/or manipulating some headers. In some cases, it
>> could be just as good as setting the User-Agent where all that happens
>> is setting the Authorization header with a token. In some other cases,
>> it could mean