One of the nice features of golang is that you can simply distribute your programs through executables, meaning the user doesn’t need to have custom libraries to install / run your software: just download the executable and you’re set.
What Go really does is to bundle together all your
*.go files in a single,
platform-dependent executable, that
can be run with a single click — which works perfectly in 99% of our use cases.
All of this seems great, until you have to bundle different kind of files
in your application, for example an
.yml config file or an
How would you approach this? Enter the trick of the year.
The idea is that you can create a go source file which contains all of the non-go files you need to bundle, something of this sort:
1 2 3 4 5 6 7 8 9 10 11 12 13
and in your code you can then require those files
by just doing
go build, then, all of your assets will
be “included” in your final binary.
Now, you could argue that writing code like this isn’t ideal, and that is true — that is why you’ll find go-bindata useful, as it generates all of the code automatically:
1 2 3
To access the contents you now just have to import your module and call the
1 2 3 4 5 6 7 8
Pretty neat, eh?
I wrapped all of this together in a github repo,
where you can see the asset
and how it can be included in go code with go-bindata:
this is something I had to do in one of my libraries, touchy,
and that I automated through a Makefile
go-generate for me, too lazy :)).
PS: on a side note, have you heard of nexe? It’s a compiling tool for node, which seems to alleviate the pain of distributing node executables.