Open nonspecialist opened 10 years ago
This is complicated, at the moment, due to the fact that git2go (the primary golang binding for libgit2) is tracking the alpha, development branch of libgit2.
This leaves us at a decision point, at least for the near future: we can track git2go and libgit2 (which should be possible given that the distributable artifact is a mostly-static binary, but complicates the build environment considerably) or we can cheat and shell out to execute local git binaries (which makes the build environment trivially simple at the expense of reducing security and trustworthiness of the distributed binary, and increasing the complexity of the runtime environment)
My preference is to see just how hard it's going to be to temporarily complicate the build environment, and keep distributing a runtime that's a dependency-free and trustworthy as possible.
I'm having a horrible time getting git2go integrated. I can build the latest libgit2, and generate a static library, and even build a mostly-static binary on Fedora/CentOS/RHEL -- but ubuntu doesn't ship static libraries for most things, which leaves it depending on various shared libraries at runtime.
I haven't even started looking at OSX (which I expect to be even more of a nightmare).
So the decision now seems to be:
The decision seems clear to me -- suck it up and accept dynamic linking. We produce packages for Linux anyhow, and will be for OSX shortly too, so I don't think it's a showstopper.
Putting some kickoff notes at https://github.com/realestate-com-au/credulous/wiki/Local-git-repo-design-thoughts