This panic has caused me trouble many times over the last year: panic: http: multiple registrations for /debug/requests
goroutine 1 [running]: net/http.(*ServeMux).Handle(0x5c47ba0, 0x511cbc5, 0xf, 0x5223160, 0x515f730) /usr/local/go/src/net/http/server.go:2353 +0x239 net/http.(*ServeMux).HandleFunc(0x5c47ba0, 0x511cbc5, 0xf, 0x515f730) /usr/local/go/src/net/http/server.go:2368 +0x55 net/http.HandleFunc(0x511cbc5, 0xf, 0x515f730) /usr/local/go/src/net/http/server.go:2380 +0x4b golang.org/x/net/trace.init.0() /Users/buchanae/src/golang.org/x/net/trace/trace.go:115 +0x42 This happens because more than one package is vendoring golang.org/x/net and importing x/net/trace, which has a global handler registration in an init() function. This has been discussed briefly here https://github.com/golang/go/issues/20478 and here https://github.com/golang/go/issues/24137 Unfortunately, we're using docker as a library (import github.com/docker/docker/client) and docker also vendors golang.org/x/net. The same is true for github.com/golang/gddo/httputil. We need to vendor golang.org/x/net in our root application for other dependencies, to avoid breaking changes such as https://github.com/golang/net/commit/cbb82b59bc5199680c5bf34109e12097095dca9b I'm stuck. I have a PR with a useful feature which is blocked until I can find a way around this. The new feature uses a package which imports golang.org/x/net/trace. I've read that "dep" will flatten vendor trees and solve this issue. I haven't tried it. Will "vgo" solve this issue as well? Can't we get rid of the global registrations in the trace package? I must have fought this issue 10+ times in the last year. -- 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. For more options, visit https://groups.google.com/d/optout.
