Because go is always statically compiled for whatever platform you're on at the time, the default behavior is for importing go libraries using `go get` from the command line actually does a git clone of the code and compiles it on the fly (because go's compiler is pretty darn fast) and caches statically compiled versions of dependencies for builds. Go-Arrow follows this same typical golang pattern that you don't distribute a shared object binary but rather the go tool pulls the code and compiles the relevant code as needed. Because the import path tells it the full path to the go.mod file (the top of the module) it knows that it only needs the go/arrow directory tree for the module and as such it doesn't clone the entire git repo.
-----Original Message----- From: Antoine Pitrou <anto...@python.org> Sent: Monday, August 23, 2021 2:00 PM To: dev@arrow.apache.org Subject: Re: [C++][Go] CGO For Dataset API Integration Le 23/08/2021 à 19:53, Matthew Topol a écrit : > The only thing I don't like it being a private module in the Go > implementation is distribution. For native go code, consumers can just > perform `go get` and have it work. But for this interface, it would require > both consumers of the module and any consumers of those consumers to have a > local built version of this library locally when building their Go code. Easy > to static link in for distributing binaries, but not for library builders. Hmm, I think I'm lacking some context. Do consumers of Go-Arrow code typically recompile Go-Arrow instead of using an existing binary?
