Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support mod feature #43

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

Support mod feature #43

Show file tree
Hide file tree
Changes from 5 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
bc7df92
Support mod feature
Jul 7, 2019
d333677
update Readme for mod feature
Jul 7, 2019
1afd978
1 mod feature support; 2 replace zipkin package
Oct 4, 2019
81c4418
update --mod_module flag description
Oct 4, 2019
29395be
1 simplify the way to new service with modules; 2 update README; 3 re…
Dec 15, 2019
1e719fa
1 revert the go.sum; 2 update README.md
Jan 20, 2020
f22a832
fix:1 Qual context; 2 Add parent level go.mod file check
Jan 21, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,3 +18,4 @@ vendor/

.idea
*.iml
.vscode/
12 changes: 11 additions & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,7 @@ GoKit Cli needs to be installed using `go get` and `go install` so `Go` is a req
- [Generate the service](#generate-the-service)
- [Generate the client library](#generate-the-client-library)
- [Generate new middlewares](#generate-new-middleware)
- [Mod feature support](#mod-feature-support)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [Mod feature support](#mod-feature-support)
- [Module support](#mod-feature-support)

- [Enable docker integration](#enable-docker-integration)

# Installation
Expand All @@ -31,11 +32,19 @@ kit help

Also read this [medium story](https://medium.com/@kujtimii.h/creating-a-todo-app-using-gokit-cli-20f066a58e1)
# Create a new service
The kit tool use modules to manage dependencies, please make sure your go version >= 1.3, or
GO111MODULE is set on. If you want to specify the module name, you should use the --module flag, otherwise, the module name in the go.mod file will be set as your project name.
```bash
kit new service hello
kit n s hello # using aliases
```
This will generate the initial folder structure and the service interface
or
```bash
kit new service hello --module github.com/{group name}/hello
kit n s hello -m github.com/{group name}/hello # using aliases
```

This will generate the initial folder structure, the go.mod file and the service interface

`service-name/pkg/service/service.go`
```go
Expand All @@ -47,6 +56,7 @@ type HelloService interface {
// e.x: Foo(ctx context.Context,s string)(rs string, err error)
}
```
When you are generating the service and the client library, the module name in the go.mod file could be autodetected.

# Generate the service
```bash
Expand Down
1 change: 1 addition & 0 deletions cmd/root.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,7 @@ func init() {
RootCmd.PersistentFlags().BoolP("debug", "d", false, "If you want to se the debug logs.")
RootCmd.PersistentFlags().BoolP("force", "f", false, "Force overide existing files without asking.")
RootCmd.PersistentFlags().StringP("folder", "b", "", "If you want to specify the base folder of the project.")

viper.BindPFlag("gk_folder", RootCmd.PersistentFlags().Lookup("folder"))
viper.BindPFlag("gk_force", RootCmd.PersistentFlags().Lookup("force"))
viper.BindPFlag("gk_debug", RootCmd.PersistentFlags().Lookup("debug"))
Expand Down
3 changes: 3 additions & 0 deletions cmd/service.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@ import (
"github.com/kujtimiihoxha/kit/generator"
"github.com/sirupsen/logrus"
"github.com/spf13/cobra"
"github.com/spf13/viper"
)

var serviceCmd = &cobra.Command{
Expand All @@ -24,4 +25,6 @@ var serviceCmd = &cobra.Command{

func init() {
newCmd.AddCommand(serviceCmd)
serviceCmd.Flags().StringP("module", "m", "", "The module name that you plan to set in the project")
viper.BindPFlag("n_s_module", serviceCmd.Flags().Lookup("module"))
}
36 changes: 20 additions & 16 deletions generator/generate_service.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1683,35 +1683,39 @@ func (g *generateCmd) generateRun() (*PartialGenerator, error) {
jen.Lit("URL"),
jen.Id("*zipkinURL"),
),
jen.List(jen.Id("collector"), jen.Err()).Op(":=").Qual(
"github.com/openzipkin/zipkin-go-opentracing", "NewHTTPCollector",
jen.Id("reporter").Op(":=").Qual(
"github.com/openzipkin/zipkin-go/reporter/http", "NewReporter",
).Call(jen.Id("*zipkinURL")),
jen.Defer().Id("reporter").Dot("Close").Call(),
jen.List(jen.Id("endpoint"), jen.Id("err")).Op(":=").Qual(
"github.com/openzipkin/zipkin-go", "NewEndpoint",
).Call(
jen.Lit(g.name),
jen.Lit("localhost:80"),
),
jen.If(jen.Err().Op("!=").Nil()).Block(
jen.Id("logger").Dot("Log").Call(
jen.Lit("err"),
jen.Id("err"),
),
jen.Qual("os", "Exit").Call(jen.Lit(1)),
),
jen.Defer().Id("collector").Dot("Close").Call(),
jen.Id("recorder").Op(":=").Qual(
"github.com/openzipkin/zipkin-go-opentracing", "NewRecorder",
).Call(
jen.Id("collector"),
jen.Lit(false),
jen.Lit("localhost:80"),
jen.Lit(g.name),
),
jen.List(jen.Id("tracer"), jen.Id("err")).Op("=").Qual(
"github.com/openzipkin/zipkin-go-opentracing", "NewTracer",
).Call(jen.Id("recorder")),
jen.Id("localEndpoint").Op(":=").Qual("github.com/openzipkin/zipkin-go", "WithLocalEndpoint").Call(jen.Id("endpoint")),
jen.List(jen.Id("nativeTracer"), jen.Id("err")).Op(":=").Qual(
"github.com/openzipkin/zipkin-go", "NewTracer",
).Call(jen.Id("reporter"), jen.Id("localEndpoint")),
jen.If(jen.Err().Op("!=").Nil()).Block(
jen.Id("logger").Dot("Log").Call(
jen.Lit("err"),
jen.Id("err"),
),
jen.Qual("os", "Exit").Call(jen.Lit(1)),
),
jen.Id("tracer").Op("=").Qual(
"github.com/openzipkin-contrib/zipkin-go-opentracing", "Wrap",
).Call(
jen.Id("nativeTracer"),
),
).Else().If(jen.Id("*lightstepToken").Op("!=").Lit("")).Block(
jen.Id("logger").Dot("Log").Call(
jen.Lit("tracer"),
GrantZheng marked this conversation as resolved.
Show resolved Hide resolved
Expand All @@ -1728,8 +1732,8 @@ func (g *generateCmd) generateRun() (*PartialGenerator, error) {
),
),
jen.Defer().Qual(
"github.com/lightstep/lightstep-tracer-go", "FlushLightStepTracer",
).Call(jen.Id("tracer")),
"github.com/lightstep/lightstep-tracer-go", "Flush",
).Call(jen.Id("context.Background()"), jen.Id("tracer")),
Copy link
Owner

@kujtimiihoxha kujtimiihoxha Jan 20, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to use Qual here context is missing in the imports.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, I fix it and update the pr

).Else().If(jen.Id("*appdashAddr").Op("!=").Lit("")).Block(
jen.Id("logger").Dot("Log").Call(
jen.Lit("tracer"),
Expand Down
23 changes: 23 additions & 0 deletions generator/new_service.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,7 @@ package generator

import (
"fmt"
"os/exec"
"path"
"strings"

Expand Down Expand Up @@ -40,6 +41,12 @@ func NewNewService(name string) Gen {
// Generate will run the generator.
func (g *NewService) Generate() error {
g.CreateFolderStructure(g.destPath)
err := g.genModule()
if err != nil {
println(err.Error())
return err
}

comments := []string{
"Add your methods here",
"e.x: Foo(ctx context.Context,s string)(rs string, err error)",
Expand All @@ -53,3 +60,19 @@ func (g *NewService) Generate() error {
)
return g.fs.WriteFile(g.filePath, g.srcFile.GoString(), false)
}

func (g *NewService) genModule() error {
exist, _ := g.fs.Exists(g.name + "/go.mod")
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we want to add the dependencies manually, at least the once we depend on after running kit g s

Copy link
Author

@GrantZheng GrantZheng Jan 20, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @kujtimiihoxha :）

Why we need to maintain multiple services under the same package？
I think it has two scenes：
The one scene is that we just maintain multiple services and convenient to manage the project. There have no relation between services and services are started by there own main.go file ({service}/cmd/main.go).

The other scene is that we want to construct a monolithic project that contains multiple services under the same package. There have some dependency between services and the monolithic project is started only by one main.go file which needs to be create manually at the service's parent level. In addition, we should also delete the go.mod file at the service level and create a go.mod file manually at the parent level.

About the one scene, I think it is of small significance and rarely used in this way. We only need to cover most of the usage scenarios. There's no need to support.

About the other scene, I think it is significant. But I do not recommend realizing the function at the kit tool. The responsibility of kit tool is just construct our services. If we want to construct a monolithic project, we should do manually as follows:

  1. delete the go.mod file at the service level and create a go.mod file manually at the parent level
  2. create a main.go file at the service's parent level
    But, when we need to add functions to a service , the kit g s {service} will not work well, because we delete the go.mod file under the service level, the module name in the go.mod file can not be autodetected. To solve this problem, the kit tool should add a function that if the go.mod file can not be found in the service level, it will use the go.mod file in parent level to generate service and client library.

What do you think?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are right.

One other thing that came to my mind now is that with how it is implemented now we are not maintaining backwards compatibility with already existing projects that use kit.

Is there a way to only use modules when the user wants to do that ?

Basically only use mod if --module is provided OR the go.mod file is detected in the service folder.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

About compatible with the already existing projects，we may have two ways, I think.

The one is that we should use tag vesion to manage our feature, such as checkout two new branches named release/v0.1.0 and release/v0.2.0 from the master and tag the release/v0.1.0 branch code v0.1.0 which should run kit commands under the GOPATH, and then switch to release/v0.2.0 branch, merge code from feature/mod_support branch, tag v0.2.0 under the release/v0.2.0 branch. If the user want to use the GOPATH ,he can use the v0.1.0 version; if the user want to use the module feature, he can use the v0.2.0 version.

The other is that continue to support GOPATH in our new version, if user run kit n s {service} without module flag, it will use the old way to new and generate service and client library.

I think the first way is better than the second. I want to quote some word from https://blog.golang.org/modules2019.

Our aim is for Go 1.13, scheduled for August 2019, to enable module mode by default (that is, to change the default from auto to on) and deprecate GOPATH mode. In order to do that, we’ve been working on better tooling support along with better support for the open-source module ecosystem.

So, I think there is no need to compatible with GOPATH in our new version. We should guide the user to use the new module feature. If the user have to use the GOPATH, he could switch to the old version v0.1.0.

What do you think about this? :)

if exist {
return nil
}

moduleName := g.name
if viper.GetString("n_s_module") != "" {
moduleName = viper.GetString("n_s_module")
}
cmdStr := "cd " + g.name + " && go mod init " + moduleName
cmd := exec.Command("sh", "-c", cmdStr)
_, err := cmd.Output()
return err
}
Loading