Re: [gentoo-dev] new eclass: go-live.eclass for handling go live ebuilds

[William Hubbs]

On Fri, Jun 05, 2015 at 12:54:45AM -0400, Mike Frysinger wrote:
> On 04 Jun 2015 14:10, William Hubbs wrote:
> > # @ECLASS: go-live.eclass
>
> since we're going to have a common go eclass, and i don't think we'll want to
> call it "go.eclass", this too probably should not be go-xxx.  if we assume the
> base one will be "golang.eclass", then this should be golang-xxx.eclass.  i'd
> prefer golang-vcs.eclass myself as that's the naming we've been moving towards.
 
 I'm not convinced yet that we are going to have a base eclass for all
 go ebuilds, but I can rename this one easily enough to
 golang-vcs.eclass.

> > # @MAINTAINER:
> > # William Hubbs <williamh@g.o>
> > # @BLURB: Eclass for fetching and unpacking go repositories.
> > # @DESCRIPTION:
> > # This eclass is written to ease the maintenance of live ebuilds
> > # of software written in the Go programming language.
>
> this should note the ebuild is responsible for depending on the right vcs
> packages.  e.g. if you use git, then you need to depend on git.

Since "go get" fetches $EGO_PN and its dependencies, there is no way an
ebuild author could get this right without reading all of the import
statements in the source for their package and all of its dependencies.
I don't really want to ask ebuild authors to keep up with all of that.

> although ...
>
> > # @ECLASS-VARIABLE: EGO_PN
> > # @REQUIRED
> > # @DESCRIPTION:
> > # This is the import path for the go package. Please emerge dev-lang/go
> > # and read "go help importpath" for syntax.
> > #
> > # Example:
> > # @CODE
> > # EGO_PN="github.com/user/project"
> > # @CODE
>
> can't we automate some of the common hosts ?  if it says github, we know it's
> going to be using at least git.
 
I'm seeing two options. I can either let users emerge the vcs's they
need if something breaks or pull in all vcs's go supports.

Which way is best?

...

> > 	if [[ ${EVCS_OFFLINE} ]]; then
> > 		export GOPATH="${S}:${GOPATH}"
>
> what if GOPATH isn't set ?  should this always be appending a colon ?

I thought it would always be set at this point because it was initially
set to ${EGO_STORE_DIR} in the env_setup function. What I can do, if it
makes things more clear, is to replace the value of GOPATH instead of
prepending it.

...

> > 	go get -d -t -u -v -x "$EGO_PN"
>
> needs braces around ${EGO_PN}, and shouldn't this be calling `die` ?
>
> would also be useful to show the command you're running:
> 	set -- go get -d -t -u -v -x "${EGO_PN}"
> 	echo "$@"
> 	"$@" || die
 
You are correct; we should be calling die here. However, I suspect an
upstream bug because the following returns an error:

$ cd /home/william/go
$ export GOPATH=/home/william/go
$ go get -d -t -u -v -x golang.org/x/tools

go downloads everything, then errors out with a message about "no
buildable source files in /home/william/go/src/golang.org/x/tools"

This isn't an error because you build the tools from the subdirectories
of the project.

...

> > 	export GOPATH="${S}:${GOPATH}"
>
> same questions here

See my comment above about GOPATH; the same thing applies here.

The eclass with your changes is attached.

William