Use vendoring tool dep instad of committing the vendor folder

[mavimo]

The repository already contains Gopkg.toml and Gopkg.lock but the vendoring folder is committed in codebase.

• update Gopkg.toml and Gopkg.lock to use the last version of packages (see
  2b7d2a2)
• introduce dep as vendoring tool in CI and build process (see 1fa718f)
• remove /vendor folder from repository (see f174d07)

I still using dep since is the tool used in this repo but maybe we should consider to move to module when go1.11 will be released

[xetys]

As I'm inexperienced with dep, this looks good to me

[slintes]

too late, but: afaik most projects commit vendor, because the pros are stronger than the cons: https://github.com/golang/dep/blob/master/docs/FAQ.md#should-i-commit-my-vendor-directory

just my 2 cents :)

[JohnnyQQQQ]

@slintes I agree with you

[xetys]

I was on the same site when deciding to commit it in. I merged that PR as I am not that experienced with the go ecosystem at all and it made sense at that moment.

So I would do a little vote here, at least @mavimo @JohnnyQQQQ @slintes, maybe @eliasp

React on this comment with

• 👍 if you feel including the vendor dir is better, or
• 👎 if you feel excluding the vendor dir as of this PR is better

[xetys]

addition: if we choose to commit it back, I still would like to have that in an extra PR, as the updates to the Gopkg files were needed anyway

[JohnnyQQQQ]

I spun up a PR for using the go.mod approach introduced with golang 1.11 #181

[mavimo]

I suggest to use go mod for golang 1.11 and dep for go<=1.10

Dependency vendoring imho should not be done since we are going to introduce dependency in the codebase that should be omitted (we have technology that allow us to do that 😃)

The only issue that this generate is the requirement to download dependency when we pull the repo, that IMHO is acceptable for a contributor.

[JohnnyQQQQ]

Dependency vendoring imho should not be done since we are going to introduce dependency in the codebase that should be omitted

Can you clarify what you mean?

[mavimo]

@JohnnyQQQQ sorry :P
I mean we should not commit vendor dependency into the project repository, but should managed as dependency like other language/technology (eg: mvn for Java, composer for PHP, npm for Javascript, ...).

• https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md
• https://dev.to/tommym9/should-you-commit-your-vendor-folder-to-git-2kae
• https://medium.freecodecamp.org/an-intro-to-dep-how-to-manage-your-golang-project-dependencies-7b07d84e7ba5

Duplicating the vendor code in our project is an anti-pattern that IMHO should not be done in any project.

[slintes]

2 of the 3 the con arguments of getcomposer (history duplication, git submodule problems) are not relevant because go dep doesn't add the .git directory of dependencies into the vendor directory.
And the best pro argument is coming from the javascript/npm world: when someone deletes a project you depend on, you still have the code and can compile, until you find a replacement (https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/).

(but at the end I don't care that much, this topic only catched my eyes while cleaning up my github notification mails)

[JohnnyQQQQ]

Never thought about someone deleting a whole project I depend on 😨