[Starlingx-discuss] [Build] go loanguage

Victor Rodriguez vm.rod25 at gmail.com
Fri Nov 23 22:30:40 UTC 2018

On Fri, Nov 23, 2018 at 1:48 PM Scott Little <scott.little at windriver.com> wrote:
> 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.

For me it works : curl
https://raw.githubusercontent.com/golang/dep/master/install.sh | sh

> 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.

I am in favor of providing both go get and dep since they are for
different reasons


> Opinions?
> Scott
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss

More information about the Starlingx-discuss mailing list