When writing go code with one package and one command I would structure it like
package.go ./cmd/command1/main.go With package.go being at the root of the workspace and ./cmd/command1/main.go naming an executable which primarily make use of the package. Now I _migh_ have vendored package.go without checking in /vendor/ but I almost ever vendored ./cmd/command/ even with checking in the vendor folder. In the past I also included a minimal Dockerfile in ./cmd/command1/ which did a `go install -v` and, as I checked ./cmd/command1/vendor/ into source control, was done even without internet connection. With vgo, where would I put the go.mod file? How would I maintain this mostly encapsulated approach for `go install -v` I am note against fetching from a repository / whatever service vgo will support to load dependencies- it's just what I preferred upto now. Just curious how this future workflow might look like or how others think about that. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
