Closed maxnoel closed 6 years ago
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
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:
"import github.com/globalsign/mgo"
.GetBSON
/SetBSON
, but does so by importinggopkg.in/mgo.v2
and using its types.GetBSON
orSetBSON
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
:bson.Setter
(to implement the interfaceSetBSON
's argument must be aglobalsign/mgo/bson.Raw
but the method takes agopkg.in/mgo.v2/bson.Raw
, making it unsuitable).bson.Getter
(GetBSON
returns(interface{}, error)
), but the concrete types returned byGetBSON
, being foreign toglobalsign/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)?