I realized that when writing `require go-micro.dev/v4 v4.1.0` in the
`go.mod` file, `go mod tidy` will install that exact version of
`go-micro.dev/v4`. As of right now, v4.1.0 is an outdated version, and
preferably we shouldn't be updating gomu's Go Modules template everytime
a new release is tagged, but still want gomu users to generate projects
using the latest Go Micro version.
In an attempt to solve this problem, I'm opting to add a new Makefile
rule for new projects generated by gomu, `update` that runs `go get -u`.
This aggressively updates any dependencies your Go Modules project may
have. `go mod tidy` is then able to prune the `go.mod` and `go.sum`
files by removing the unnecessary checksums and transitive dependencies
(e.g. `// indirect`), that were added to by go get -u due to newer
semver available.
Put one and one together and you get two. In addition to adding an
`update` rule to the Makefile generated for new projects by gomu, I'm
also updating the proto and client comments printed when new projects
have been generated to promote the `update` rule.
References:
- https://stackoverflow.com/questions/67201708/go-update-all-modules
go get: installing executables with 'go get' in module mode is deprecated.
To adjust and download dependencies of the current module, use 'go get -d'.
To install using requirements of the current module, use 'go install'.
To install ignoring the current module, use 'go install' with a version,
like 'go install example.com/cmd@latest'.
For more information, see https://golang.org/doc/go-get-install-deprecation
or run 'go help get' or 'go help install'.
There's really no point in having the `generator` be embedded in a
`file` package so we remove the `file` package and make the `generator`
package a first class citizen instead.
* Move file generation to new package
* Use text/template instead of html/template
* Make config variables more consistent
* Combine generate files and print comments there
* Add gomu generate command
* Refactor project templating to file library
* Determine client earlier
Gomu expects a `map[string]string` type response back, but this isn't
always the case. When Gomu calls a service endpoint that responds with,
let's say, a key where its value is a map or a list, Gomu would be
unable to decode that response. By expecting a `map[string]interface{}`
type response, Gomu is able to decode those responses as well.
* Use internal runtime package for gomu run
This change refactors the `gomu run` command to use Go Micro's internal
runtime package in order to run services. Not only does this clean up
duplicate functionality between Go Micro and Gomu, but also adds the
feature to Gomu to run remote projects. For example, the following
command pulls in a remote project and runs it locally.
```bash
gomu run github.com/auditemarlow/helloworld
```
The `gomu run` command remains backwards compatible. By invoking `gomu
run` in a Go Micro project directory, Gomu will simply run that project.
* Simplify Gomu's command registering
By leveraging Go's `init()` function, we can simplify registering
commands just a tad.
