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'.
* add errors.As
convert target err to *Error, return false if err don't match *Error
* update errors.As to (*Error, bool)
* fixing FromError panic issue when err is nil
Though some of the Zap logger option can be customized through
plugins/logger/zap.Options, this change allows go.uber.org/zap.Option be
be injected directly for deeper customization.
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.
The helloworld examples found in the `google.golang.org/grpc/examples`
package were imported multiple times as different versions, resulting in
package conflicts. By running `go mod tidy`, these conflicts are
resolved and the gRPC client plugin can now be imported again.
* 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
