I have an early prototype of a go-chop (and chomp) library and set of binaries, at https://github.com/mcandre/go-chop
But I'm not sure of the best way to structure my Go stuff. Am I doing it right? Ideally, when other Go users go-get my project, they receive a working library that they can use, as well as a chop and chomp binary in PATH.
Is there a way to organize my Go project to facilitate this? What's the command(s) that other Go users would use to install my stuff?
评论:
shovelpost:
mcandre:Your Makefile is 40% of the repository's code...
Anyways, if you want to have multiple commands, the most common way I've seen is to have a
cmd
folder then two or more folders, one for each command which then will contain themain.go
of the command.By following that layout, when someone go gets your repo, they will also get all the commands.
So in your case, instead of
cli-chomp.go
andcli-chop.go
you would have acmd
folder, containingchomp
andchop
folders containingcli-chomp.go
andcli-chop.go
respectively or you could even rename them asmain.go
.Helpful article: Five suggestions for setting up a Go project
shovelpost:Your Makefile is 40% of the repository's code...
Lol yeah, that's been my crutch while I learn Go idioms.
When a user runs
go get ...
, does Go automatically build the .go files, and even place the binaries on PATH? Or what would be the typical steps for a Go user to begin using the cmd/... programs from a Go package URL?
howeyc:As far as I know, just doing
go get github.com/someuser/somerepo
will install somerepo under your $GOPATH. Any packages will be installed under $GOPATH/pkg and any commands under $GOPATH/bin. So basically the only thing the user has to do isgo get
and then they can instantly use the commands of somerepo.Helpful read: https://golang.org/doc/articles/go_command.html#tmp_3
I would recommend what shovelpost suggested.
I have something that I believe follows such a convention.
https://github.com/howeyc/ledger
The root is the package and the cmd directory has three separate executables.
