Gin: gopkg usage

[itsjamie]

Currently, the usage of gopkg is viral, such that if a contributed Gin package or other third-party library uses gopkg as the import path for a library, they cannot work with users who use the github.com/gin-gonic/gin import path, and vice versa.

With the development of https://github.com/golang/dep continuing it looks like Go will likely standardize the package management story at some point around the /vendor folder with a tool that uses semver and a manifest file to manage reproducible builds.

I'm raising this now because I've had to write a similar wrapper to https://github.com/gin-contrib/sessions just because of this virality of gopkg.

I would like to propose instead that the official contrib libraries either vendor a tagged version of gin-gonic/gin that they support for testing, which would be flattened by any of the earlier mentioned dependency mgmt tools. Alternatively, simply notate the major version of Gin they support in README.md and ensure that CI pulls the latest major when running tests.

Thank you for the consideration.

[jostyee]

./main.go:33: cannot use r (type *"github.com/gin-gonic/gin".Engine) as type *"gopkg.in/gin-gonic/gin.v1".Engine in argument to pprof.Register
./main.go:34: cannot use sentry.Recovery(raven.DefaultClient, false) (type "gopkg.in/gin-gonic/gin.v1".HandlerFunc) as type "github.com/gin-gonic/gin".HandlerFunc in argument to r.Use

Please stop it, or at lease sync packages in gin-contrib.

[localvar]

agree with @jostyee

I'm currently using Glide as the dependency management tool.
because all gin-contrib packages refers the main gin package as 'gopkg.in/gin-gonic/gin.v1',
my application are also using it as this.

but in gin.go (and the examples), the render package is imported as github.com/gin-gonic/gin/render, so after I do 'glide up', there are two copies of gin in my vendor folder, one is gopkg.in/gin-gonic/gin.v1, the other is github.com/gin-gonic/gin.

and after I implement my own view render, I got below error:

.\main.go:34: cannot use newViewRender() (type *ViewRender) as type "xxxxx/vendor/github.com/gin-gonic/gin/render".HTMLRender in assignment:
        *ViewRender does not implement "xxxxx/vendor/github.com/gin-gonic/gin/render".HTMLRender (wrong type for Instance method)
                have Instance(string, interface {}) "xxxxx/vendor/gopkg.in/gin-gonic/gin.v1/render".Render
                want Instance(string, interface {}) "xxxxx/vendor/github.com/gin-gonic/gin/render".Render

I'm switch to use github.com/gin-gonic/contrib for the contribute packages now.

[tboerger]

True, we must use a single path and not mixed paths. We have to decide finally which way to go. Today it looks like the gopkg.in path can be dropped in favor of dependency managers

[greysond]

You should probably put this in the readme, as it still suggests using gopkg.

[thinkerou]

please see https://github.com/gin-gonic/gin#installation, now gin have used github.com/gin-gonic/gin package path, not gopkg.in/...., closing.