Hey Andrew and Russ,
Thanks for answering here.
Yes, that’s actually something I’m going to revert - because in the current state (which if I understand correctly is the one proposed by Go Modules) we lost support for govendor and dep.
The biggest user of Badger is Dgraph, which uses govendor to manage dependencies, and breaking Dgraph (or any other client) build’s to support Go Modules doesn’t seem like the right trade-off.
It seems a fix might be done to dep to eventually be able to understand this internal import path change, but my current situation makes it so either I support Go Modules or others - and in this situation it is safer to chose the tools that already worked before.
In addition to that, not supporting Go modules doesn’t make it too complicated for those who do use them to still use Badger, thanks to the +incompatible directive.
I think the bigger point here is about my disagreement with the statement here:
I understand that changing the import path has benefits, but we also have other mechanisms to control this via Gopkg.toml, go.mod, or whatever flavor of requirements.txt we might be using. Wouldn’t that be enough? That would indeed “do less to enable more”, instead of (IMHO) artificially baking into Go Modules a best practice that not everyone follows.
Finally, I have a question about the workaround @adg mentions here:
In this case, do I need to simply add that go.mod in a v2 directory, or do I also need to add Go code in there? I wouldn’t want to maintain a series of types aliases and function wrappers just to support Go Modules either.
Again, thanks for the help!