Advice for publishing go packages with conda

[stuarteberg]

Now that conda-forge has this feedstock for golang itself, has anyone experimented with publishing conda binaries for their own (or others') go packages? Can anyone recommend "best practices" for distributing go packages via conda?

For instance, I'm guessing we'll need a standard location for $GOPATH within the conda environment. These are the candidate locations I can think of:

• ${CONDA_PREFIX} (intermingle go's bin, etc. directories with the conda env's. Is that crazy)?
• ${CONDA_PREFIX}/go (i.e. the same as ${GOROOT} -- is that allowed?)
• ${CONDA_PREFIX}/gopath

What else should I worry about? I know nothing about go's own package management scheme. Would it be possible to mix-and-match go packages with conda packages (similar to pip and conda)?

I'm not very experienced with go, so sorry if any of the above is stupid/naïve.

[jakirkham]

Any thoughts on this one @nehaljwani? Also guessing you are making use of this with the Concourse CI work, @msarahan, do you have any thoughts on how this should be done?

[nehaljwani]

I am, by no means, an expert in Go. I have only tried to build a few go packages.

IIUC, GOPATH is set for specifying the location of the workspace, where all the source code and dependencies are checked out.

The thing is, for each go project, specifying GOPATH can be different, because some go projects specify the directory to which you should be setting/appending to GOPATH for building them. For example, for building houdini, I had to append $SRC_DIR/deps to the GOPATH: https://gist.github.com/nehaljwani/4a8c27b4fe8536bec240f636111da0c0

While actually building the go project for making a conda package, the way directories are laid out with Conda Build, it becomes tricky sometimes, so for example, in the case of go-bindata, I have to use 'path to where source is unpacked or cloned' as the GOPATH and then move all the source contents to a specific path (or create a symlink) for creating the correct 'src' directory structure as mentioned here: https://golang.org/doc/code.html#Workspaces

export GOPATH="${SRC_DIR}"
GO_BINDATA_SRC="${GOPATH}/src/github.com/jteeuwen/go-bindata"
mkdir -p "${GO_BINDATA_SRC}"
mv -v "${SRC_DIR}"/* "${GO_BINDATA_SRC}/" || true

pushd "${GO_BINDATA_SRC}"
go install ./...

mkdir -p "${PREFIX}/bin"
cp "${GOPATH}/bin/go-bindata" "${PREFIX}/bin/"
mv "${GO_BINDATA_SRC}/LICENSE" "${SRC_DIR}"

${CONDA_PREFIX}/go (i.e. the same as ${GOROOT} -- is that allowed?)

I don't think ${CONDA_PREFIX}/go is good because that already contains the code for the standard library, and I would want my code to be separate from that.

If you are only building go code and not making conda packages, then it's really up to you. If you want strict isolation between environments, then you could set GOPATH to ${CONDA_PREFIX}/some_folder_name. However, setting and unsetting GOPATH would be strictly controlled by you and if you forget to unset GOPATH, then it may cause trouble later while building other go code in another environment which might depend on a different version of the dependency. Also, if you ever delete this environment, then this path will also be nuked.

In general, I would always recommend to keep the GOPATH local to the checked out source code (less headaches). The only problem with this approach is that if you work on multiple go projects, and some of them share common source dependencies, then you will be cloning/checking them out for each, eating network bandwidth and disk space.

[jakirkham]

@sodre, as you have been building a few go packages, do you have any thoughts on this?