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.
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.
* Update greeter references to helloworld
* Add new client command
With this change, Gomu users will be able to generate template projects
for clients to services. Additionally vendor support has been built in
so Gomu users can now generate projects using fully qualified package
names, for example:
```bash
gomu new service github.com/auditemarlow/helloworld
```
This will create a new service project `helloworld` with its module name
already set to `github.com/auditemarlow/helloworld`. Likewise, Gomu
users can then generate client projects in the same manner:
```bash
gomu new client github.com/auditemarlow/helloworld
```
This will create a `helloworld-client` project that uses the protobufs
found in the `github.com/auditemarlow/helloworld` service. This removes
at least some strain in configuring these module dependencies yourself;
you can just scaffold them outright from the start.
Although the default client project is highly opinionated, it works
straight out of the box and has Skaffold in mind. Gomu users should be
able to get going in a matter of seconds.
* Update README
* Fix Skaffold pipeline for generated client projects
* Update greeter references to helloworld
* Add new client command
With this change, Gomu users will be able to generate template projects
for clients to services. Additionally vendor support has been built in
so Gomu users can now generate projects using fully qualified package
names, for example:
```bash
gomu new service github.com/auditemarlow/helloworld
```
This will create a new service project `helloworld` with its module name
already set to `github.com/auditemarlow/helloworld`. Likewise, Gomu
users can then generate client projects in the same manner:
```bash
gomu new client github.com/auditemarlow/helloworld
```
This will create a `helloworld-client` project that uses the protobufs
found in the `github.com/auditemarlow/helloworld` service. This removes
at least some strain in configuring these module dependencies yourself;
you can just scaffold them outright from the start.
Although the default client project is highly opinionated, it works
straight out of the box and has Skaffold in mind. Gomu users should be
able to get going in a matter of seconds.
* Update README
