I’m not qualified to make any judgment on the technical merits of several dependency management solutions, but as someone working primarily in Go, the churn of solutions is starting to have a real cognitive cost.
Some of the solutions suggested from a couple of the Go devs in that “thread” sound.. almost surreal to me.
My favorite one so far:
We’ve been discussing some sort of go release command that both makes releases/tagging easy, but also checks API compatibility (like the Go-internal go tool api checker I wrote for Go releases). It might also be able to query godoc.org and find callers of your package and run their tests against your new version too at pre-release time, before any tag is pushed. etc.
– https://github.com/golang/go/issues/24301#issuecomment-390788506
With all the cloud providers starting to offer pay-by-the-second containers-as-a-service, I see no reason we couldn’t provide this as an open source tool that anybody can run and pay the $0.57 or $1.34 they need to to run a bazillion tests over a bunch of hosts for a few minutes.
There’s not much Google secret sauce when it comes to running tests.
– https://github.com/golang/go/issues/24301#issuecomment-390790036
That sounds… kind of crazy for anyone that isn’t Google scale or doesn’t have Google money.
Are the Go devs just /that/ divorced from the (non Google) reality that the rest of us live in?
Kind of crazy, but not super crazy. As another example, consider Rust’s crater tool. When the Rust team are trying to evaluate the impact of fixing a syntax quirk or behavioural bug, they make a version of the Rust compiler with the change and a version without, and boot up crater to test every publicly available Rust package with both compiler versions to see if anything breaks that wasn’t already broken.
crater runs on Mozilla’s batch-job infrastructure (TaskCluster), and Mozilla is much, much smaller than Google scale. On the other hand, they’re still bigger than a lot of organisations, and I believe a crater run can take a few days to complete, so it’s going to be a lot more than “$1.34 … for a few minutes” on public cloud infrastructure.
I get the spirit of those responses; we’re getting to the point with cloud services were that kind of integration test suite could happen cheaply.
But it is not the answer to the problems that prompted those responses.
Dependency management is hard, and there isn’t a perfect solution, mvs is a cool approach and I’m curious how it shakes out in practice, but to OP’s point, I’m not sure I can do another switch like we’ve done up to now
Manual Vendoring ($GOPATH munging) govendor dep vgo
whatever fixes the problems with vgo
Agreed. I have a couple of projects that I have switched solutions at least 4 or 5 times already (manual GOPATH munging, godep, gpm, gb, dep), because each time it was either a somewhat commonly accepted solution, or seemed the least worst alternative (before there was any kind of community consensus).
The whole vgo project seems somewhat surreal. It pulled out the rug from dep, which everyone thought was on its way to becoming the official way to do dependencies.
And yet I’m not sure I’ll really miss it. Having worked with it the last 6 months it’s god-awful slow, local vendoring doesn’t really work well with git, download proxy servers are a nice idea that was never really implemented in any plausible way, private repos are challenging. It feels half finished and forgotten, with no traction in months.
sboyer didn’t even have the time to actually write down his objections.
And how is it a single developer manages to supplant an entire open source project on his own? And even more, how does he manage to do that and produce something better?
I played with vgo. Its fast, works well with the existing go tool, its dead simple to use, and has a robust proxy solution to avoid left-padding. Somehow it manages to preserve Go’s distributed dependency model.
I’m not qualified to make any judgment on the technical merits of several dependency management solutions, but as someone working primarily in Go, the churn of solutions is starting to have a real cognitive cost.
Some of the solutions suggested from a couple of the Go devs in that “thread” sound.. almost surreal to me.
My favorite one so far:
That sounds… kind of crazy for anyone that isn’t Google scale or doesn’t have Google money.
Are the Go devs just /that/ divorced from the (non Google) reality that the rest of us live in?
Kind of crazy, but not super crazy. As another example, consider Rust’s crater tool. When the Rust team are trying to evaluate the impact of fixing a syntax quirk or behavioural bug, they make a version of the Rust compiler with the change and a version without, and boot up crater to test every publicly available Rust package with both compiler versions to see if anything breaks that wasn’t already broken.
crater runs on Mozilla’s batch-job infrastructure (TaskCluster), and Mozilla is much, much smaller than Google scale. On the other hand, they’re still bigger than a lot of organisations, and I believe a crater run can take a few days to complete, so it’s going to be a lot more than “$1.34 … for a few minutes” on public cloud infrastructure.
I get the spirit of those responses; we’re getting to the point with cloud services were that kind of integration test suite could happen cheaply.
But it is not the answer to the problems that prompted those responses.
Dependency management is hard, and there isn’t a perfect solution, mvs is a cool approach and I’m curious how it shakes out in practice, but to OP’s point, I’m not sure I can do another switch like we’ve done up to now
Agreed. I have a couple of projects that I have switched solutions at least 4 or 5 times already (manual GOPATH munging, godep, gpm, gb, dep), because each time it was either a somewhat commonly accepted solution, or seemed the least worst alternative (before there was any kind of community consensus).
I have yet to migrate a project between dependency managers.
The old ones work exactly as well as they always have.
I’ve reverted to using govendor for all new projects. I might be able to skip dep if vgo proves to be a good solution.
similar story for us; govendor works better with private repos
The whole vgo project seems somewhat surreal. It pulled out the rug from dep, which everyone thought was on its way to becoming the official way to do dependencies.
And yet I’m not sure I’ll really miss it. Having worked with it the last 6 months it’s god-awful slow, local vendoring doesn’t really work well with git, download proxy servers are a nice idea that was never really implemented in any plausible way, private repos are challenging. It feels half finished and forgotten, with no traction in months.
sboyer didn’t even have the time to actually write down his objections.
And how is it a single developer manages to supplant an entire open source project on his own? And even more, how does he manage to do that and produce something better?
I played with vgo. Its fast, works well with the existing go tool, its dead simple to use, and has a robust proxy solution to avoid left-padding. Somehow it manages to preserve Go’s distributed dependency model.
I really don’t know what to make out of it all.