Revived the example with a new structure and docs
Description of changes:
The docs have been updated to follow the code structure more in sync as well as utilize a more modern code generation using Makefile
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
- Why use vendoring still instead of regular modules without vendoring?
- Should the try it out instructions have non-GOPATH instructions since that is on the deprecation/removal path now?
This is great @DennisSSDev, let's try to move it to the finish line!
The vendor folder is explicitly required to generate the binary twirp tools (look at the makefile please). This is the simplest way I could make it, besides effectively forcing the end-user to manually install twirp on their machine. If we want to go towards that route, we can remove the vendor folder and make the makefile command look for a local version of the twirp tool binaries, but I think that would make playing around with this example faaar more difficult
The vendor folder is explicitly required to generate the binary twirp tools
The requirement to allow protoc work with a specific version of protoc-gen-go and protoc-gen-twirp, is to have them installed in the PATH. You can do this using GOBIN when installing the tool (e.g. GOBIN=./_bin go install ...), and/or making sure that the PATH has that folder when calling protoc (e.g. PATH=./_bin:$PATH protoc ...).
The go install command will download the dependency with the right version specified in go.mod. If the vendor folder is present, then the download is not needed. But in this case, it is reasonable to require connection to Github, because this example is already downloaded from Github.