xhd2015/xgo

IDE Integration: fake go script to integrate with IDEs without plugin modification

xhd2015 opened this issue · 1 comments

As discussed in #221 (comment), and similar issues like #205, #210

IDE integration is necessary for xgo to work un-surprisingly.

The main problem is, when user clicks build, run and test buttons from the IDE, the IDE or its plugin will execute go build, go run and go test.

And when xgo is used, these commands should be replaced with xgo build, xgo run and xgo test , correspondingly.

At first it seems reasonable to ask each IDE or plugin to support customizing go command, i.e. a config the allows user to replace go with xgo.

However that's nearly impossible because there are too many IDEs and too many non-IDE tools that simply uses the naked go command, for example, ginko-go.

I come up with a clean solution that nearly takes no extra effort, but only need user to prepend a directory to their PATH variable. The prepended directory, say /tmp/xgo/bin will only contain a script, named go, with the following content:

#!/usr/bin/env bash

# remove /tmp/xgo/bin inside PATH, to see which go is used
# e.g.  PATH=/tmp/xgo/bin:/usr/bin  -> PATH=:/usr/bin
real_go=$(PATH=${PATH/'tmp/xgo/bin'/} which go)

export XGO_REAL_GO_BINARY=$real_go

cmd=$1
if [[ $cmd = build || $cmd = test || $cmd = run ]] ; then
     xgo "$@"
    exit
fi

"$real_go" "$@"

It will invoke go or xgo based on the command passed in, when the command is build,test or run, xgo will be used. Otherwise, go will be used.

This works even when nested, i.e. when xgo calls go, if XGO_REAL_GO_BINARY is set, that real go binary will be used.

The overall flow:

  1. user invokes xgo shadow
  2. xgo shadow creates the directory ~/.xgo/shadow, and build the binary to shadow
    • the shadow binary will implement the logic as said above
  3. xgo shadow prints the path
  4. user add the printed path to PATH variable

From user's point of view:

  1. type xgo shadow -> prints the path
  2. add the printed path to PATH variable