TL;DR: importing badger v2.0.0 requires using Go modules, let us know if this is a big deal for your project
Hi there, friends of the badger!
I wanted to give an early warning to all of you using Badger and planning to migrate to v2.0.0 as soon as it comes out in a couple of days.
The latest and best version of Badger uses Go modules, as requested by a large part of our community. Unfortunately, dep and many other dependency management tools have not been adapted to Go Modules and specifically aren’t able to handle the versioned import paths such as github.com/dgraph-io/badger/v2.
Badger v2.0.0 will not be supported for those not on Go modules
We expect the Go team to work on this situation and at least finalize the proposed change in this PR.
So, what do you have to do to adopt Badger v2?
if you’re already using Go modules, you’re good!
if you’re using dep, you will need to migrate to Go modules or find a temporary workaround (please share!)
For those using other dependency management tools, they might or might not support Go modules - all of the ones we tried (govendor, glide, dep, godep) did not support this.
If your team would be impacted by this, as you were counting on migrating to v2 soon but you can’t adopt Go modules yet, please let us know and we’ll try to figure out how to support your usecase. You can get in touch with me directly at francesc@dgraph.io.
This post (and especially the tweet announcing it) imply that there is simply no way to make Badger v2.0.0 work with both modules and dep. This turns out not to be the case. If you wanted to make Badger v2.0.0 work fine with both Go modules and prior tools, the solution is to put the v2 code into a v2 subdirectory in the root of the repo. Then both Go modules and non-module-aware code fetches will find it. See my comment from June 26 for details.
That is, there is a way to avoid breaking any users. The approach you’ve chosen instead is fine as long as you realize that you are choosing to break dep users and likely users of other pre-modules vendor-maintenance programs. Perhaps you are choosing it for what you think is a good reason, like not liking to have a v2/ subdirectory. That’s fine. Just understand that you are making the choice. You are not forced into it.
We expect the Go team to work on this situation and at least finalize the proposed change in this PR.
Also, for what it’s worth, the Go team is not maintaining, supporting, or pushing changes into Dep. Personally, I think that PR is a good idea, but whether to merge it is up to Sam Boyer and the other Dep contributors.
And of course even if that PR is merged, any other pre-modules vendoring solutions would still be broken unless you use a v2/ subdirectory.
