Go modules

[jmcarp]

Now that go 1.11 is out with support for go modules, we don't need a third-party dependency management tool. This patch switches to go modules for dependencies, and also drops a few unused dependencies. I didn't run tests with your docker image, but the golang version will have to be upgraded there for tests to run with docker.

[jmcarp]

Ping @nickatsegment. I'll fix the merge conflicts if you all are interested in switching to go modules. Now that it's the official packaging tool, I figure we'll want to switch over eventually.

[nickatsegment]

Yep, I'm not against the idea. If you can fix up those conflicts, that'd be great. I'd like to see an automated build work :)

That said, it might be too early to get rid of vendor.json entirely. I'm not sure how that affects libs that depend on chamber?

[jmcarp]

Conflicts resolved! You can test by install go 1.11 and running make all.

About vendor.json, are other packages importing chamber? Not sure I see the use case, and at least based on github search, this might not be happening: https://github.com/search?l=Go&q=%22github.com%2Fsegmentio%2Fchamber%22&type=Code

[nickatsegment]

Cool! I'll take a look at it today.

You're probably right that nobody's importing it, but Segment does internally for sure (in a private repo). :) Also, I think we'll want to support people using go get as an install method, and probably < go 1.11

[nickatsegment]

It occurs to me that as long as the vendored packages in vendor/ are correct, having a vendor.json is not important for go get regardless of version.

But we also do govendor sync during builds. TBH I think that doing so is a mistake: we shouldn't be updating the vendored packages except by hand, and then committing them. If that's the case, insisting devs use go modules to do so is not a huge ask, I don't think, then we can just get rid of govendor entirely.

I took your fork and added two things:

• vendor.json back in; I still want to think about this to figure out if we need it or not
• circle jobs to check that go get . works on the various versions of go that we support.

https://github.com/segmentio/chamber/tree/go-modules
https://circleci.com/gh/segmentio/chamber/299

[eculver]

I'm not a huge fan of Go modules. Unless there's a very compelling reason, I don't think we should make the switch until support is official in Go 1.12.

At the very least, we should keep vendor.json and let users manually opt-in at their discretion so that we don't have to potentially deal with two dependency management tools. This means keeping govendor in our build toolchain for the time being.

Just my $0.02...

[nickatsegment]

Yep, I think keeping both at least until Go 1.12 is the way to go. We'll have to maintain both, but that shouldn't be too bad.

I'm skeptical of Go modules as well, but I think trying them out in a real project is a worthwhile experiment.

[jmcarp]

@nickatsegment: the approach you took in https://github.com/segmentio/chamber/tree/go-modules makes sense to me. I don't have a strong opinion about go modules, but now that they've landed in core, I'm guessing third-party package managers and metadata formats will gradually fall out of favor and lose support.

[nickatsegment]

Superseded by #144