Switch to dep

[adunham-stripe]

This switches to using dep for dependency management, and attempts to reproduce the existing lock.json as faithfully as possible.

[groob]

@adunham-stripe thanks for adding dep. I think that's a nobrainer as I've moved to dep for almost every other go project.

I'm a bit against checking in /vendor as the lockfile is usually sufficient and adding the vendor folder affects github code review/stats a lot.
Would love to hear your thoughts on the subject.

[adunham-stripe]

For libraries, I generally agree that you should not check in vendored code. However, for binaries, I tend to enjoy having everything checked in - it insulates against someone moving/deleting a repository and then being entirely unable to build something. However, I don't have super strong feelings here, so if you'd prefer not, I'm happy to drop the last commit.

[groob]

Lets do that. I agree with you about the potential for that kind of disaster scenario but from past experience it hasn't been a practical issue. I'd put the option on the table for future updates.

Another question. I tend to prefer 1 commit per pull request and squash on merge. Doing that ensures a clean linear history of the project in master and avoids a lot of the in progress commits common in FOSS PRs. But it does require you to rebase after code review if you want to keep your commits clean.

Would you be ok if I enable that for this repo?

[adunham-stripe]

Okay, force-pushed and removed that last commit. As for the squash-and-merge, I don't have super-strong opinions, so that sounds reasonable to me! 👍

[groob]

Perfect. I'll try to put out a contributing guide and add CI to this project shortly. Thanks for the PR!