Update generate_gomod step in makefile

[MartinForReal]

update generate_gomod step in makefile

[roblaszczak]

Hello, @MartinForReal. Can you add some context why the current method should be changed? :)

[MartinForReal]

Please refer to https://github.com/ThreeDotsLabs/watermill/pull/75#discussion_r285383479https://github.com/ThreeDotsLabs/watermill/pull/75#discussion_r285383479

[sagikazarmark]

I don't really agree with the vendoring part. In case of a library it doesn't really matter. Also, it makes the repository larger, which in turn means longer installation time. Missed the fact that vendor/ is ignored.

Other then that I agree:

• Regenerating the go.mod file seems to be an anti-pattern for multiple reasons
  • It does not work well with MVS if you always upgrade the lowest possible version to the latest. It will always upgrade the dependencies to their latest version, even if not necessary.
  • Reinitializing dependencies also means, that any custom configuration will be lost from go.mod
• go get -u github.com/golang/protobuf/proto also seems like a bad move, since in case of go modules it upgrades all dependencies and writes it in the go.mod file. Again, in case of a library it's not necessary, leave that to the user.

Personally I think a go mod tidy from time to time should be enough.

When a direct dependency needs updating, I use go get PACKAGE (no -u). This will update the dependency to the latest available version and leaves indirect dependencies at their default version (which again: should be fine for a library).

[roblaszczak]

Ok, we will work on it during splitting Pub/Subs to separated repositories. In that scenario, this repository will be almost free of external dependencies and Pub/Subs repos will contain only necessary dependencies == it will require to download only these dependencies that you will really need :)

[sagikazarmark]

This thread might also be interesting for you: spf13/viper#707