go build Integration

[joefitzgerald]

Suggested by @mattetti in #9. Add the option to run go build on save and display any errors in Atom.

[joefitzgerald]

@kevinsawicki This issue is dependent on resolution of an issue (that I believe is in a private Atom repo, and so not visible / linkable) to ensure the current environment is available to Atom (and its packages). This would ensure $GOPATH is set, and does not need to be configured within Atom. Additionally, it increases the likelihood that $GOROOT/bin is available on the path, making go accessible without an absolute path.

Reference: http://discuss.atom.io/t/atom-command-doesnt-pass-environment-variables-to-atom/1596 / #9.

[joefitzgerald]

@probablycorey Notification that this refers to an issue you created against Atom.

[mattetti]

I started making some progress, mattetti@b55540c the issue is that indeed without $GOPATH available, the compilation won't work. I think we might be able to find a workaround without requiring a change to atom.

[mattetti]

My PR requires the user to set their GOPATH in the preferences for now, I think that's totally acceptable. If the user doesn't set the path, a warning is displayed on save.
I also let the user set a path to find their go binary since again, the user ENV isn't available.
Users can't turn off this feature.

[fatih]

Is it not possible that Atom reads it automatically from the environment variables instead of setting it manually?

[joefitzgerald]

@fatih: Atom is affected by an issue that affects all OS X GUI apps – because of the way the OS launches processes in this way, the user's environment is not available. However, if you launch your app from the command line (e.g. by installing Atom's command line tools, and then running atom on the command line) there is the possibility that the environment could be provided to Atom.

The issue there is that Atom uses a technique to open the app that does not provide the current environment to the app:

open -a $ATOM_PATH -n --args --executed-from="$(pwd)" --pid=$$ $@

If this was changed to use env to launch Atom, the current environment is provided to the app:

env open -a $ATOM_PATH -n --args --executed-from="$(pwd)" --pid=$$ $@

This is an issue with the Atom command line tools, but we cannot link to a specific issue because (I believe) it's in a private repo. Hope that clarifies things.

[fatih]

When you add them to launchd.conf the GUI reads it then from there:

~ ❯ cat /etc/launchd.conf
setenv PATH /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

I do this for both MacVim and SublimeText.

[joefitzgerald]

Yes, this is also how I address things also:

setenv GOROOT /usr/local/go
setenv GOPATH /Users/jfitzgerald/go
setenv PATH /Users/jfitzgerald/go/bin:/usr/local/go/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

But it would be preferable to fix the Atom command line tools to launch Atom with the current environment so that you could potentially use different $GOPATH values for different projects (putting aside religion of one $GOPATH vs many $GOPATH's).

This is an issue that affects many, many packages - essentially anything that launches external processes.

[probablycorey]

@joefitzgerald When I open Atom via the command line tools I already have access to the user environment using process.env. Does this solve the problem, or is there something else that needs to be fixed.

[joefitzgerald]

@probablycorey The issue is in the way the command line tools launch Atom:

which atom
/usr/local/bin/atom

cat /usr/local/bin/atom
#!/bin/sh
ATOM_PATH=${ATOM_PATH-/Applications/Atom.app}
ATOM_BINARY=$ATOM_PATH/Contents/MacOS/Atom

if [ ! -d $ATOM_PATH ]; then sleep 5; fi # Wait for Atom to reappear, Sparkle may be replacing it.

if [ ! -d $ATOM_PATH ]; then
  echo "Atom application not found at '$ATOM_PATH'" >&2
  exit 1
fi

while getopts ":wtfvhs-:" opt; do
  case "$opt" in
    -)
      case "${OPTARG}" in
        wait)
          WAIT=1
          ;;
        help|version|foreground|test)
          EXPECT_OUTPUT=1
          ;;
      esac
      ;;
    w)
      WAIT=1
      ;;
    h|v|f|t)
      EXPECT_OUTPUT=1
      ;;
  esac
done

if [ $EXPECT_OUTPUT ]; then
  $ATOM_BINARY --executed-from="$(pwd)" --pid=$$ $@
  exit $?
else
  open -a $ATOM_PATH -n --args --executed-from="$(pwd)" --pid=$$ $@
fi

# Used to exit process when atom is used as $EDITOR
on_die() {
  exit 0
}
trap 'on_die' SIGQUIT SIGTERM

if [ $WAIT ]; then
  while true; do
    sleep 1
  done
fi

In particular, the following line results in the current environment not being available to Atom (I'm using iTerm2 + zsh):

open -a $ATOM_PATH -n --args --executed-from="$(pwd)" --pid=$$ $@

The following change to the line (prepending env to open) does result in the current environment being available to Atom:

env open -a $ATOM_PATH -n --args --executed-from="$(pwd)" --pid=$$ $@

ENV(1)                    BSD General Commands Manual                   ENV(1)

NAME
     env -- set and print environment

SYNOPSIS
     env [-i] [name=value ...] [utility [argument ...]]

DESCRIPTION
     env executes utility after modifying the environment as specified on the command
     line.

I know open should work on its own, but it doesn't seem to be working for me in Terminal or in iTerm2. However - it is possible this is only experienced when opening the package in development mode (Shift-Cmd-I) - how is that launch occurring, and does it also inherit the same environment as the Atom process launched by the command line?

Launched with only open:

language-go: error launching format command [gofmt] – Error: spawn ENOENT – current PATH: [/usr/bin:/bin:/usr/sbin:/sbin] gofmt.coffee:28

Launched with env open (and updating the path to the utility to a nonexistent path to cause the plugin to print the current PATH):

language-go: error launching format command [/no/path/to/gofmt] – Error: spawn ENOENT – current PATH: [/Users/jfitzgerald/.rbenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/usr/local/go/bin:/Users/jfitzgerald/go/bin:/Users/jfitzgerald/Projects/Packer:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/go/bin:/usr/local/go/bin:/Users/jfitzgerald/go/bin] gofmt.coffee:28

[mattetti]

Note that even if we fix the opening from terminal, users coming from
finder won't have the env setup.
On Mar 13, 2014 6:54 AM, "Joe Fitzgerald" notifications@github.com wrote:

@probablycorey https://github.com/probablycorey The issue is in the way
the command line tools launch Atom:

which atom
/usr/local/bin/atom

cat /usr/local/bin/atom
#!/bin/sh
ATOM_PATH=${ATOM_PATH-/Applications/Atom.app}
ATOM_BINARY=$ATOM_PATH/Contents/MacOS/Atom

if [ ! -d $ATOM_PATH ]; then sleep 5; fi # Wait for Atom to reappear, Sparkle may be replacing it.

if [ ! -d $ATOM_PATH ]; then
echo "Atom application not found at '$ATOM_PATH'" >&2
exit 1
fi

while getopts ":wtfvhs-:" opt; do
case "$opt" in
-)
case "${OPTARG}" in
wait)
WAIT=1
;;
help|version|foreground|test)
EXPECT_OUTPUT=1
;;
esac
;;
w)
WAIT=1
;;
h|v|f|t)
EXPECT_OUTPUT=1
;;
esac
done

if [ $EXPECT_OUTPUT ]; then
$ATOM_BINARY --executed-from="$(pwd)" --pid=$$ $@
exit $?
else
open -a $ATOM_PATH -n --args --executed-from="$(pwd)" --pid=$$ $@
fi

Used to exit process when atom is used as $EDITOR

on_die() {
exit 0
}
trap 'on_die' SIGQUIT SIGTERM

if [ $WAIT ]; then
while true; do
sleep 1
done
fi

In particular, the following line results in the current environment not
being available to Atom (I'm using iTerm2 + zsh):

open -a $ATOM_PATH -n --args --executed-from="$(pwd)" --pid=$$ $@

The following change to the line (prepending env to open) does result
in the current environment being available to Atom:

env open -a $ATOM_PATH -n --args --executed-from="$(pwd)" --pid=$$ $@

ENV(1) BSD General Commands Manual ENV(1)

NAME
env -- set and print environment

SYNOPSIS
env [-i] [name=value ...] [utility [argument ...]]

DESCRIPTION
env executes utility after modifying the environment as specified on the command
line.

I know open should work on its own, but it doesn't seem to be working for
me in Terminal or in iTerm2. However - it is possible this is only
experienced when opening the package in development mode (Shift-Cmd-I) -
how is that launch occurring, and does it also inherit the same environment
as the Atom process launched by the command line?

Launched with only open:

language-go: error launching format command [gofmt] – Error: spawn ENOENT – current PATH: [/usr/bin:/bin:/usr/sbin:/sbin] gofmt.coffee:28

Launched with env open (and updating the path to the utility to a
nonexistent path to cause the plugin to print the current PATH):

language-go: error launching format command [/no/path/to/gofmt] – Error: spawn ENOENT – current PATH: [/Users/jfitzgerald/.rbenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/usr/local/go/bin:/Users/jfitzgerald/go/bin:/Users/jfitzgerald/Projects/Packer:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/go/bin:/usr/local/go/bin:/Users/jfitzgerald/go/bin] gofmt.coffee:28

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-37534958
.

[joefitzgerald]

@mattetti thanks, should have re-asserted that also 👍 – though I'm not sure that is fixable. Most people are mutating their environment in .zshrc, .bash_profile, etc, and it's not reasonable for Atom to be able to read our mind about which shell we're using.

I think I would be satisfied with having to launch Atom from the command line to get the current environment - it's how I open Atom mostly today anyway. Just means that package authors need to accommodate both scenarios (use the environment – if set – otherwise, rely on configured values in Preferences). Perhaps there is something there to generalize as a pattern in Atom preferences?

[joefitzgerald]

Closing in deference to joefitzgerald/go-plus#1