Take over gopkg.in/mgo.v2 ?

[maxnoel]

Hi!

Currently, https://gopkg.in/mgo.v2 references the old version of mgo (https://github.com/go-mgo/mgo), meaning that anyone who imports "https://gopkg.in/mgo.v2" or one of its sub-packages will get/vendor/use an old, unmaintained version of mgo. This is unfortunate.

Worse still, consider the following use case:

• I'm writing a program that interacts with MongoDB. I'm using "import github.com/globalsign/mgo".
• I'm depending on an external library that exports types that implement GetBSON/SetBSON, but does so by importing gopkg.in/mgo.v2 and using its types.
• I never explicitly call GetBSON or SetBSON on those types. I just use them as attributes to my own structs that get serialized in the database.

My program will compile just fine, but at runtime, serialization will work erratically and deserialization not at all, because from the point of view of globalsign/mgo:

• The types exported by the external library do not implement bson.Setter (to implement the interface SetBSON 's argument must be a globalsign/mgo/bson.Raw but the method takes a gopkg.in/mgo.v2/bson.Raw, making it unsuitable).
• They do, however, implement bson.Getter (GetBSON returns (interface{}, error)), but the concrete types returned by GetBSON, being foreign to globalsign/mgo/bson, do not trigger the correct serialization flows.

Given that https://github.com/go-mgo/mgo is unmaintained and clearly documented as such, have you considered requesting a takeover of https://gopkg.in/mgo.v2 so that it redirects to this repository, and then switching the entire lib to canonical imports (through // import "gopkg.in/mgo.v2" directives)?

[domodwyer]

Hi @maxnoel

I appreciate the frustration! Unfortunately we have no control over gopkg.in - it's actually maintained by the original mgo repo author so he would have to change the endpoint to this repo - I can't say how receptive he would be to changing it.

All I can suggest is maybe try vendoring this repo under the gopkg.in/mgo.v2 path at your project root, which will trick your dependencies to use this version assuming they don't vendor their own dependencies. It's definitely a bit of a hack and you would have to go back to using the mgo.v2 import everywhere in your code.

Maybe having a lightweight fork of your dependencies is best?

Dom