RFC: Gin-templates generator

[hoangmirs]

Why

In our gin-template, we're letting users build a binary file (nimble-gin) then using it to create a new project. https://github.com/nimblehq/gin-templates#usage

The nimble-gin command is just on top of the cookiecutter. https://github.com/nimblehq/gin-templates/blob/develop/cmd/create.go#L34

But I found some issues when using it:

• If we build the binary file, it requires more extra steps and more effort, but we get the same result.
• We have to set the $GOPATH to build the binary, if I don't set it, it would show an error.

How about using the cookiecutter command directly?

$ cookiecutter https://github.com/nimblehq/gin-templates
# or
$ cookiecutter https://github.com/nimblehq/gin-templates --checkout branch-name

Who Benefits?

Gin developers

[hoangmirs]

I voted for cookiecutter. I think it's unnecessary to build a new command based on it as cookiecutter just provides a few options to generate a project from the template. I think we can consider building a command if we mainly generate the project with it, I mean using golang to generate project (copy files, insert text to file, ...)

[olivierobert]

@hoangmirs @gutakk The advantage I see with using nimble-gin is that when/if cookiecutter is dropped and replaced by a custom generator then the interface for end-users would not change. The command nimble-gin abstracts the fact that cookiecutter is used. Interfaces should remain the same while the implementation can change.

What about storing the built package (binary) in the repository so that it does not need to be built? Would that solve the issues? The binary could be built via the CI when merging to master for automation purposes 💭

[gutakk]

@olivierobert I got your point now. This can be done in the next release (after Nimble Growth). Maybe the simpler way is to add more steps about setting up the GOPATH to README.

What do you think @hoangmirs