Closed akutz closed 8 years ago
Hmmm, I think I may have figured this one out. It appears the initial Atom launch spawns a server that then launches helper processes for each window.
[0]akutz@pax:libstorage$ ps alx | grep Atom
501 1757 1 0 31 0 2543396 1168 - S ?? 0:00.30 /Applications/Atom.app/Contents/Frameworks/Electron Framework.framework/Resources/crashpad_handler --database=/tmp/Atom Crashes --url=http://54.249.141.255:1127/post --handshake-fd=44
501 62321 1 0 63 0 3538232 100880 - S ?? 0:09.19 /Applications/Atom.app/Contents/MacOS/Atom --executed-from=/Users/akutz/Projects/go/src/github.com/emccode/rexray --pid=62316 --path-environment=/Users/akutz/Library/Python/2.7/bin:/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/bin:/Users/akutz/Scripts/devops/tools:/Users/akutz/Scripts:/Users/akutz/Scripts/krakatau:/Users/akutz/Source/launch4j:/Users/akutz/Projects/ruby/igit:/Users/akutz/.brew/bin:/Users/akutz/.rubies/ruby-2.1.2/bin:/Users/akutz/Servers/mysql/5.7.7/bin:/Users/akutz/.brew/Cellar/maven/3.3.1/libexec:/Users/akutz/Projects/go/bin:/Users/akutz/.go/1.6/bin:/Users/akutz/.brew/bin:/Users/akutz/.opt/make/4.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin -n .
501 62322 62321 0 31 0 3189412 316228 - S ?? 0:04.35 /Applications/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper --type=gpu-process --channel=62321.0.95267717 --no-sandbox --supports-dual-gpus=true --gpu-driver-bug-workarounds=13,15,24,29,40,41,45,52,58 --gpu-vendor-id=0x10de --gpu-device-id=0x0fe9 --gpu-driver-vendor --gpu-driver-version
501 62324 1 0 31 0 2483884 3256 - S ?? 0:00.01 /Applications/Atom.app/Contents/Frameworks/Electron Framework.framework/Resources/crashpad_handler --database=/tmp/Atom Crashes --url=http://54.249.141.255:1127/post --handshake-fd=44
501 62325 62321 0 31 0 3744868 281168 - S ?? 0:19.98 /Applications/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper --type=renderer --js-flags=--harmony --no-sandbox --lang=English --node-integration=true --enable-delegated-renderer --num-raster-threads=4 --gpu-rasterization-msaa-sample-count=8 --content-image-texture-target=3553 --video-image-texture-target=3553 --channel=62321.1.1189961200
501 62967 62321 0 31 0 3657560 210008 - U ?? 0:02.36 /Applications/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper --type=renderer --js-flags=--harmony --no-sandbox --lang=English --node-integration=true --enable-delegated-renderer --num-raster-threads=4 --gpu-rasterization-msaa-sample-count=8 --content-image-texture-target=3553 --video-image-texture-target=3553 --channel=62321.3.56792650
501 62992 61245 0 31 0 2434840 776 - S+ s002 0:00.00 grep Atom
Apparently my trick is only getting passed to the initial launch. Hmmm.
FYI, even when I change my script to do this, it still uses the helper:
env $env_vars open -n -a /Applications/Atom.app --args $tgt_dir $@
I'm not sure this is something that can be fixed...
FWIW, I got it to work by using the Atom packages atomenv and auto-run along with this updated script:
function atomp {
local atom=${ATOM-$(which atom)}
local gopath=$GOPATH
local goroot=$GOROOT
local env_vars=
local tgt_dir=${1-$(pwd)}
if [ "$tgt_dir" == "." ]; then
tgt_dir=$(pwd)
fi
local tgt_vendor_dir=$tgt_dir/vendor
shift
if [ -d "$tgt_dir" -a -d "$tgt_vendor_dir" ]; then
local tgt_vendor_dir_abs=$(cd "$tgt_vendor_dir" && pwd)
local tmp_dir=$(mktemp -d)
ln -s "$tgt_vendor_dir_abs" "$tmp_dir/src"
gopath=$tmp_dir:$gopath
fi
local atomenv=$tgt_dir/.atomenv.cson
echo "env:" > $atomenv
echo " GOROOT: \"$goroot\"" >> $atomenv
echo " GOPATH: \"$gopath\"" >> $atomenv
$atom $tgt_dir $@
}
I'd just wait for joe to finish some of the infrastructure work hes doing to goplus will resolve this problem. I've been dealing with it for awhile for my environment manager for go as well. and just decided it wasn't worth fighting atom over =)
This is fixed in Atom
>= v1.7.0
(currently in Beta @ https://atom.io/beta). Atom was not passing the current environment through to the helper process to ensure it is used in the new Atom window. This is now fixed thanks to https://github.com/atom/atom/pull/11054.
So I created a little helper for atom in my user's go profile at
$HOME/.profile.d/go.sh
(OS X):You'll note that
atomp
, when executed from the shell, will always open Atom with the GOROOT variable set (despite it not being set in general). More importantly, if Atom is opened without any arguments it assumes Atom is being opened for the current directory, or if a directory is specified it uses that directory, and then checks to see if there's avendor
directory present. The function then sets up a structure in temp space to prefix to theGOPATH
variable so that Go-Plus can correctly resolve source references from inside a projectsvendor
directory (and not complain about missing imports).This works perfectly...except when there are two Atom windows for two projects. Please see the first invocation. I'm including the call from the terminal window where I am echoing the command so you can see the environment variables are set correctly:
Please note in the above windows the highlighted
GOPATH
values match.Now watch what happens if I leave the first Atom instance open and launch a second from a different location:
In the case of as second Atom instance, Go-Plus still has the second instance's
GOPATH
value as reflecting that of the first Atom instance. However, if you see the output in the second terminal window,GOPATH
is being set to a second, unique location.Is this an aspect of Atom? A simple display bug in Go-Plus? Maybe the
GOPATH
values truly are different, but Go-Plus is only showing the original one when printed?Thoughts?