Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Go 1.11 Modules (vgo) vs dep #1959
@sdboyer Thank you for your talk Jul 18 at the GoSF meetup!
Could we get an official tldr; about how to treat
As well any links to a video of the talk?
hi, thank you! Unfortunately, the talk video got lost
i realize that guidance on these sorts of questions has been in short supply in the recent months. There actually IS more coming now, though. To that end, my TODO list looks something like this:
Items 3 and 4 will make guidance clearer on questions of what to use, i think. And, frustrating as it is, it'll be clear in retrospect why we needed to get our ducks in a row. Right now, i can say that dep will absolutely be adapting to the new world, and it won't hurt you to continue using it.
This advice is at best misleading.
Once Go 1.11 is out, it really makes very little sense for a new project not already using dep to start using it. Dep has many, many problems - some of which Sam acknowledged in the talk - and you avoid all of them, avoid taking the time to master a system that is going away, and help make Go modules better by simply using Go modules from the start.
Kubernetes, for example, is planning to jump straight from godep to Go modules, skipping dep entirely. They actually spent quite a lot of effort trying to figure out how to migrate to dep and could not quite make it work.
If you're already using dep, then it makes sense to keep using it until you're ready to make the switch - no one likes forced upgrades after all - but I think the vast majority of dep users will be very happy with the conversion to Go modules, especially since everything is integrated more smoothly into the go command.
@rsc Thanks for the update. I've been reading your blog posts and watched your SG keynote to try and get up to speed. I suppose August is quite close so one could reasonably go with tip but as you said yourself:
Couldn't an organization just choose the package file style they prefer? That is, with Gopkg.toml being the only encouraged alternative, the rest deprecated and slated for removal. Or is there a roadmap in which these other file types would also be removed from
Without knowing the intricacies this seems to be a sort of yarn vs npm style scenario.
@rsc I just went through this and its been a bit of a mess. Yes, yes I know experimental software. But go 1.11 // July 31 is coming very soon and go modules are still are still shaky. my team is considering going back to dep and revisiting in 6 months.
Issues we hit along the way -
2 was especially annoying because we just go get vgo in our ci pipeline. so one day builds started failing because latest commit of vgo had the protocol change.
These aren't fundamental problems with go modules. These are signs of a product that are not ready for launch and I would advise any team to stick with what you got till things firm up.