Go modules

[hanzei]

This PR introduces Go Modules. This allows to e.g. develop the plugin outside the GOPATH.

This is a proof of concept and not meant to be merged yet. Everybody who is interested in Go Modules is invited to try it out and give feedback.

Follow up from https://community.mattermost.com/core/pl/a1naj6a61tfa8mdyyhpjfdgw8o.

Open questions

I've opted to place go.mod in the root directory. I would be cleaner to have a separate one for the build tool, but this would increase the work when updating dependencies.

Todo

• [x] Fix make gofmt
• [x] Move build/manifest in build IMO it's fine in build/manifest
• [X] Think about using go mod vendor I don't want this

[cpanato]

/check-cla

[hanzei]

This is ready for review.

[lieut-data]

@hanzei, haven't given this a full review yet, but can you speak to removing the vendor directory? I /think/ that's independent of adopting go modules, and might still be best practice -- e.g. mattermost-server will almost certainly retain vendor even after switching. Discussion?

[hanzei]

You'r correct, you can use still use vendor with go modules. But what is the advantage of a vendor directory? The mod file pins the required dependencies. And with go modules build into the go command, no additional software is needed. (Which is an advantage vs. dep)

[lieut-data]

I think these arguments apply equally well to dep, but we still chose to vendor there. Personally, I like the fact that my code will build without needing to make any network requests, or if GitHub is down, or if the source is taken down, etc. I really dislike node_modules for all of these reasons.

[hanzei]

I'm not really see the problem. You only have to make network requests after go.mod has changed. But if you pulled the changes in go.mod the next go command will automatically download the new dependencies. And updating go.mod only happens once a month (at least for server).

The big advantage of not using vendor is that you don't end up with dozen copies of files all your projects.

[lieut-data]

Yeah, that's fair, at least in this context. Plus, I just realized we only vendored the manifest tool vs. the actual server code! Sounds good to simplify.

[cometkim]

The big advantage of not using vendor is that you don't end up with dozen copies of files all your projects.

100% agree with this.

Like dep, you do not have to manage many dependencies with version diff, and it's much faster.

I like the fact that my code will build without needing to make any network requests, or if GitHub is down, or if the source is taken down, etc. I really dislike node_modules for all of these reasons.

I think that's a problem of SaaS, not node_modules or go module. And there are many solutions for module availability: mirroring & proxying (a.k.a artifactory) and vendor directory is one of them.

At the very least, user-centric systems like plugins don't have to suffer from inconvenience for enterprise-class availability.

Even in the case of the server, the go module can still adapt to vendoring, so we can remove unnecessary diffs(−58,242 LOC for this) from our repository and manage them explicitly.

[hanzei]

@levb Gently reminder about this PR :wink:

[hanzei]

@crspeller Requesting your review, since you worked on Go Modules for the Server. I would like to hear your feedback, but this isn't urgent, if you are busy.