Open mrutkows opened 4 years ago
Why not go modules? All other golang dependency management tools are afaik deprecated in favor of it.
I also have felt the project structure of OpenWhisk cli families(client-go, cli, wskdeploy) is somewhat different from the other Go projects and I have wondered the reasons.
@markusthoemmes i am open to whatever the "approved" toolchain from GoLang... I will read up on go modules, but had seen other Google lead projects using "dep" and had only read blogs indicating "dep" was the latest/approved dep. generator/updater for Go. Thanks for the info!
@style95 @markusthoemmes my main concern was that ALL our client-side tooling projects that are based on GoLang (CLI, client-go and wskdeploy) all use the same (and latest approved dependency tooling) and each did not each use different ones that were chosen "ad hoc" and had different pitfalls. This was a direct response to a PR in go-client that I merged that had a bogus vendor.json file with tons of invalid dependencies and was dismayed to see no uniformity.
Go modules is definitely the way to go. All projects still on dep are only there because they have some legacy considerations and/or don't want to switch yet cause it has an impact.
If you need to switch tools anyway, definitely go with go modules.
Any PR should be coordinated with similar Issue/requirement in wskdeploy: https://github.com/apache/openwhisk-wskdeploy/issues/1082
Please switch and document for developers how to use/build with "Go Modules"; see https://github.com/golang/go/wiki/Modules https://levelup.gitconnected.com/switch-to-go-modules-from-go-dep-fcdd4aa41bd5
Please note that client-go chose to use govendor which has numerous problems: for reference: https://github.com/apache/openwhisk-client-go/pull/113/files