[Starlingx-discuss] [Build] go loanguage
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
> '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
> 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
> 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
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
More information about the Starlingx-discuss