[Starlingx-discuss] [Build] go loanguage

[Scott Little]

I have a designer that want to introduce a GO language package into our 
build.  This raises the question of how to handle GO's 'imports'.

First a disclaimer.  I'm not a 'GO' exports.  The following discussion 
points are based on my brief research.

Go imports are roughly akin to a 'C' language include, with one or few 
major differences.
1) It points to a directory rather than a file, which could be local or 
relative to your GOPATH
2) The convention is to use a path that is a crude approximation of the 
url from which it can be obtained. e.g. import ( 
"github.com/docker/distribution/registry/api/errcode" )
3) If the directory is NOT already present, it can probably be 
downloaded automatically with tools like 'go get' or 'dep' (aka 
golang-dep).  These tools attempt transform the path into a URI, trying 
several vcs download protocols (git, mercurial, subversion...).  
Downloads are stored under a local 'vendor' sub-directory.  There are a 
few wrinkles, like the ability of a sire to respond with a re-direct to 
another site.

There are centos rpms for a handful of core libraries, delivering code 
to /usr/share/gocode (part of your GOPATH).  However most go code has 
never been published as an rpm, and much of the remainder seems to be a 
one off rpm, with no ongoing maintenance.

'go get' just seems to grab the latest code.  Reproducibility is a big 
concern.

'dep init' solves the reproducibility concern.  It grabs the latest 
code, but also generates a 'lock' file that capture a CVS commit 
identifier (e.g. a git SHA).  Deliver the lock file with your code and 
'dep ensure' will use the lock file to download the same code every 
time.  Dep does not currently ship as an RPM.  I have a working spec 
file for dep 0.4.1.  Dep 0.5.0 needs more work.

Licenses of public go libraries seem to be permissive, at least for a 
statically linked binary, which is what we would want to ship. Not so 
sure about the inclusion of library source as an embedded vendor 
sub-directory in our own src.rpm packages.  That would be one for the 
lawyers.


So our options seem to be.
1) Create rpms of all the go libraries we need, populating 
/usr/share/gocode.  There might be some tooling available to help with this.
    Pro: Don't require network access to build.
    Pro: Reproducible builds
    Pro: License of each go rpm is hopefully clear.
    Con: We'll be adding a lot of go libraries to our manifest. Assuming 
all are available via git.
    Con: Maintenance headache.  Create spec files and compile rpms for 
the transitive set of imports. When do we upversion the rpms?
    Con: More packages we need to build

2) Allow our new go packages to include a pre-populated vendor 
sub-directory.
    Pro: Don't require network access to build
    Pro: Reproducible builds
    Con: We store snapshots of 3rd party code in the same src.rpm as our 
own code.
    Con: More complicated licensing statements.
    Con: Maintenance headache.  When do we upversion the snapshots? Who 
want's to code inspect the mess?
    Con: If we have many go packages, there may multiple copies of the 
same library spread through our code base.
    Con: Is StarlingX, and OpenStack, ok with all the go code snapshots 
being added to our gits?

3) Use 'dep init' to create a lock file.  Deliver only the lock file 
alongside our go code.  Use 'dep ensure' during the build to download 
the required libraries.
    Pro: Lowest maintenance on our part
    Pro: Don't need to store a snapshot of any go libraries, nor add it 
too our manifest.
    Con: Need network access to build, not just in the docker container, 
but all the way down to the mock instance.
    Con: Relies on the upstream server continuing to host the package.
    Con: Relies on stability of upstream server and it's network 
connectivity.  Vast majority of packages seem to come from golang.org, 
github and go.googlesource.com, so not likely a concern.

I'm inclined to option 3.

Opinions?

Scott