go-plus cannot find my gopath and no features work

[ghost]

Operating system: Xubuntu 14.04

Atom version: 1.6.0

When I start Atom with a Go file open, three dialog boxes appear. A fourth appears after I right-click on a variable and select "rename symbol under cursor".

When I click the "Run Go Get" button on each of the dialog boxes, they all become error messages:

When I first went through this process upon installing Atom, I manually installed all the required packages myself through the terminal. When I did, the command was pasted as go get -ugolang.org/x/tools/cmd/goimports. Note the lack of a space between the u and the URL; is this an issue? In any case, in my gopath, ~/go, the /bin directory now contains all the executables the dialog boxes require:

But the error still appears every time I start atom, and none of the features of go-plus work. The dialog boxes also appear in Atom Beta.

I went to the settings to configure the go-config package and feed it my gopath, but I cannot see any button to change its settings.

[joefitzgerald]

Yes, you need a space between -u and the github.... portion if you are installing these manually.

[atombender]

Same here, 4.0 broke everything for me — and I'm always launching Atom from the command line.

After installing all deps, linting and vetting stopped working, and format-on-save moves the cursor on save.

There are errors in the console about godef, but that's all.

For some reason, go-plus no longer appears under "Installed Packages". To find its setting I have to go to "Install" and search there. Not sure if Atom bug or what.

[joefitzgerald]

The settings for go-plus are now in the individual packages. What operating system are you on, and what is the output of process.env in the Chromium console?

[atombender]

Interestingly, process.env does not show my normal environment, even though I started Atom from the command line. GOPATH is not there. (Note that I have reverted to Atom 1.5 and go-plus 3.5. Edit: Apparently it upgraded itself to 1.6.0 automatically after I downgraded.)

[intabulas]

Same issue for me with 1.6 and 4.0. I have a project in my gopath, that has sub packages and launching atom from the command line (in the root of the project) gives me linter errors not being able to find the sub packages.

I also have local vendored deps that it can't find in vendor/ either.. All worked just fine with 3.5 and 1.5x

[joefitzgerald]

Is someone open to doing a screen sharing session with me tomorrow on this? I very much want to see this myself.

[maximesong]

Same issue for me with 1.6 and 4.0. It seems to work again after I upgrade to atom 1.7 beta0

[mackjoner]

@maximesong thanks.. :-)

[joefitzgerald]

So where do we stand on this issue? Is this still an issue?

[pbnsilva]

Definitely something got broken with update to atom 1.6 and go-plus 4.0. After I started atom via terminal some of the issues disappeared, but I still get several errors that seem to be related with not being able to find GOPATH (can't find import).

[joefitzgerald]

@pbnsilva what operating system are you on? Is someone open to screen sharing with me so I can see this happening myself?

[pbnsilva]

@joefitzgerald i'm on a mac 10.11 . i'm open to screen sharing, but only tomorrow

[jmelfi]

@joefitzgerald I'm on mac 10.11 and can verify that Atom 1.6.0 and go-plus 4.0 has this issue and didn't before. I'd be open to doing a screenshare or something today or tomorrow if that would help. Feel free to contact me here or by email.

[jmelfi]

@joefitzgerald I have verified that using the terminal 100% resolves my issue. It is only when launching via the Applications folder or the Dock in Mac that causes the GOPATH variable to not be passed.

[atombender]

I was wrong about process.env before. Turns out Chromium will not print the whole thing and there's a tiny … before the last brace. I can confirm that process.env.GOPATH is correct.

[c2h5oh]

Ubuntu 15.10, Atom 1.6, go-plus 4.0 - same problem

process.env does not include GOPATH. echo $GOPATH in terminal returns a valid GOPATH.

[mackjoner]

System: Mac OS X 10.11 Atom: 1.6.0 go-plus: 4.0.1

terminal open atom

GOPATH={your GOPATH} {your atom app path}/Contents/MacOS/Atom

this for me.

GOPATH=/Users/yangzhaojie/local/gocode /Applications/Atom.app/Contents/MacOS/Atom

it's work good.

[intabulas]

Happy to screen share tomorrow.

[c2h5oh]

Interesting. I've just installed 1.7beta0 and.. it fixed 1.6.0. Fix is permanent - still works after system restart.

The thing is, at least on Linux, beta channel and stable channel share nothing except ~/.atom/ directory, so there should be interaction and yet there is. ~/.atom/config.cson modification timestamp is roughly the same as 1.7.0beta0 installation timestamp - maybe there is the problem?

[ghost]

For what it's worth, when I manually installed the package, I of course included a space between the -u and the url name. I said I didn't know whether it was relevant because it seemed highly probable that whatever was being copied to the clipboard was the command that was being run internally (and thus failed).

[bakoonin]

Had similar problems with go-plus 4.0.1 on W8.1 and Atom 1.6.x. Upgrading to Atom 1.7.0-beta0 fixed it.

[sandlerben]

Had the same issue with go-plus 4.0 and Atom 1.6. Atom 1.7.0-beta fixed it.

[joefitzgerald]

Please update environment to v1.2.0 and retest if you are on OS X.

[pbnsilva]

@joefitzgerald updated and problems persist: several import errors reported by gotype.

[joefitzgerald]

@pbnsilva Please restart atom, and then provide the actual errors.

[pbnsilva]

@joefitzgerald , for example: And many others like these; stuff that is definitely on my GOPATH.

[pierrre]

@pbnsilva its a gotype/gometalinter issue: https://github.com/alecthomas/gometalinter/issues/40

[pbnsilva]

@pierrre thanks. I've disabled gotype.

[pierrre]

@pbnsilva or you can install the package

[pbnsilva]

@pierrre that would be fine for 3rd party packages, but a hassle otherwise. I'd rather rely on different tools.

[atombender]

@joefitzgerald: After upgrading environment, it seems go-plus 4.0.1 is back to how 3.5 was. Great, thanks.

However, as an aside, I really question the set of default linters now used through gometalinter, and the fact that you have to fiddle with command line options to disable the most intrusive ones.

gotype is, as @pbnsilva discovered, apparently requires referenced packages to be installed into $GOPATH first, or it will be complain. That's pointless to include in a linter — who does that while working on a file in an editor?

dupl also seems like an odd choice to include by default, since its output trends towards false positives.

I also disable golint since it makes a lot of stupid complaints about missing documentation comments, which interferes with my workflow, but that's more of a personal decision.

[Xiol]

Still having this issue on Atom 1.6.0 with environment at 1.2.0 as recommended. This is on Ubuntu 15.10 and I can confirm that Atom is seeing the correct GOPATH. My issue is exactly as described by the original reporter.

Update: Can confirm upgrading to 1.7.0-beta0 fixes the issue.

[pbnsilva]

Solution for me was to uninstall go-plus and gometalinter and use other packages, separately.

[joefitzgerald]

@pbnsilva your issues are different to those being experienced by the Ubuntu users in this thread.

Regarding your decision to uninstall gometalinter-linter, in fact one of the reasons I moved from a monolithic package to single purpose packages was to allow people to disable specific packages to turn off behavior they do not want.

If you keep go-plus installed and disable the gometalinter-linter package then you will get the benefit of additional packages included in go-plus in the future. Or you can keep an eye out for new packages and do this yourself - both are perfectly valid approaches.

[pbnsilva]

@joefitzgerald I initially had the same issues as the original poster's and started after the updates, so was reasonable to assume they were to blame.

go-plus automatically installs gometalinter. How do I disable this dependency?

[joefitzgerald]

@pbnsilva Open package settings, and click the disable button.

[joefitzgerald]

:wave: Linux folks, particularly those running Ubuntu. I believe I have reproduced your issues and I think they have to do with where you are setting your GOPATH and PATH.

• ~/.profile: If you set them here, $GOPATH will be set in Atom when you launch Atom for the first time from the launcher in the toolbar
• ~/.bashrc If you set them here, $GOPATH will be set in Atom when you launch Atom for the first time from the terminal

Thus, to ensure GOPATH and PATH are set correctly regardless of how you launch Atom, you should put the following (or similar) in both ~/.profile and ~/.bashrc:

export GOPATH=$HOME/work
export PATH=$GOPATH/bin:/usr/local/go/bin:$PATH

Obviously the above doesn't apply exactly if bash isn't your default shell, but I trust that if you're a user of a different shell, you can grok what I am saying above and apply the same principles to your particular environment.

[den-is]

Thus, to ensure GOPATH and PATH are set correctly regardless of how you launch Atom, you should put the following (or similar) in both ~/.profile and ~/.bashrc

Strange solution.

Why can't we control go settings in atom go-plus settings? My setup is:

• Fedora 23 x64
• Custom go 1.6 installation:

$ which go
/opt/go16/bin/go

zsh 5.1.1 - so i'm not using .bashrc or .profile. i do have go related records in .zshrc like:

export GOROOT=/opt/go16
export PATH=$PATH:$GOROOT/bin
export GOPATH=$HOME/projects/gohome

still have problem: when pressing go-get in those pop-ups

[joefitzgerald]

Hi @den-is, sorry you're having issues. go-plus now requires your environment to be sane. There are too many edge cases to handle if the environment isn't sane.

One of the things I want to explore with @lee-dohm is whether we should be patching the environment on Linux in the way that we do for OSX. I will do some testing today to see if that is 1) feasible and 2) desirable.

In essence, if both are true, we could have code that automatically launches your shell to get the environment you think you intend to use.

The counter argument to that would be that there is clearly a place to set your environment for GUI apps / apps launched by launcher; and the user should a) be aware of that and b) be capable of settings things differently for GUI apps than terminal apps.

[madranet]

Have you done something to fix this?

I've just run the updates again and they all installed. I didn't change anything else [I was already on go-plus 4,1,0 environment 1,2,0]. I ran process.env before and after re-trying the updates and GOPATH wasn't there the first time and was the second. The only thing I did in betweeen was open Atom's config.json file and make sure that it contained my GOPATH, which it did.

"go-plus":
    goPath: "/Users/madra/claraithe/go"

It seems almost like opening the file 'blessed' it and allowed my GOPATH to be found. Oh well. Whatever the cause, I'm back in business again.

Cheers!

BTW: Mine was the parallel issue referenced above. Thought I'd post my reply in here to keep things tidier.

[joefitzgerald]

@madranet Yes, environment v1.2.0 includes the same logic that is included in Atom >=1.7.0 to patch your environment if you open Atom from Finder, Dock, or Spotlight. Thus, whether you open it from the terminal or Finder, Dock, or Spotlight, you have a sane environment.

You can delete that config and it'll still work.

[jbreitbart]

For me putting the config in .profile and .bashrc is not working even though I am using bash.

$ cat .profile 
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.

####### GO
#export GOROOT=$HOME/bin/go_appengine/goroot
export GOROOT=/usr/local/go
export GOPATH=$HOME/workspace/go
PATH=$GOROOT/bin:$PATH:$HOME/bin/go_appengine/goroot
#######

# if running bash
#if [ -n "$BASH_VERSION" ]; then
#    # include .bashrc if it exists
#    if [ -f "$HOME/.bashrc" ]; then
#   . "$HOME/.bashrc"
#    fi
#fi

# set PATH so it includes user's private bin if it exists
#if [ -d "$HOME/bin" ] ; then
#    PATH="$HOME/bin:$PATH"
#fi

#export PATH="$PATH:$HOME/.rvm/bin" # Add RVM to PATH for scripting

#[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*

process.env does not contain $GOPATH.

[joefitzgerald]

Remember, for the most part ~/.profile changes will require a reboot to be reflected correctly (there are other ways, but a reboot is the simplest to explain).

[joefitzgerald]

Also, try to avoid setting GOROOT if you can avoid it.

[joefitzgerald]

Finally, please ensure $GOPATH/bin is in your PATH. Sorry for the staccato responses.

[jbreitbart]

Got it. Looks like I did not restart the GUI session properly and the old .profile was still active. Thanks for your patience :smile:

[joefitzgerald]

:+1: happy to help.

[narenaryan]

I solved the issue by making sure all the below check boxes are ticked

Here are points I observed

• Always make sure you are working on /usr/local/go/bin

• Make sure GOPATH is in both ~/.zshrc and ~/.profile i.e these commands should be there in your ~.zshrc (or) ~/.bashrc and ~/.profile

  export GOPATH=/home/naren/mygo export PATH=$PATH::/usr/local/go/bin export PATH=$PATH:$GOPATH/bin`

Now install go-plus from package installer in Atom. Everything will work fine.

[vith]

Just ran into another way this can happen: processes started by nautilus (aka GNOME Files) were not receiving environment variables that were set in ~/.profile until I added dbus-update-activation-environment --systemd --all to the end of ~/.profile (the --systemd flag may be unnecessary for this particular situation).

Opening files with their default handler, right clicking and choosing "Open With...", or right clicking a folder and choosing "Open in Terminal" all had this problem.

Starting a terminal directly from GNOME Shell and running atom was working fine, as was starting Atom directly from GNOME Shell.

This affects at least GNOME 3.20 on Arch Linux.

This is of course not go-plus's fault, but I suspect others may end up here with the same problem.

edit: Looks like this will be fixed in GNOME 3.22 if not backported. commit, bug

[Sammyjroberts]

SYSTEM INFORMATION

• Ubuntu 16 64 bit

  ATOM INFORMATION

• Atom : 1.8.0
• Electron: 0.36.8
• Chrome : 47.0.2526.110
• Node : 5.1.1

ERRORS

• package github.com/nsf/gocode: cannot download, $GOPATH not set. For more details see: go help gopath
• package github.com/alecthomas/gometalinter: cannot download, $GOPATH not set. For more details see: go help gopath
• cannot find package "github.com/gorilla/mux" in any of:at line 8 col 2 /usr/lib/go-1.6/src/github.com/gorilla/mux (from $GOROOT) ($GOPATH not set) (build)
• mux is installed /home/sammy/work/src/github.com/gorilla and running my application from command works as inted

echo $GOPATH

/home/sammy/work

Really would love to get all features out of this great plugin, but running goimport never works. running go get, go install, and all other go commands work great from command line.

in the meantime I have run all the go gets in terminal and things are working.

let me know if you guys can help or if I can provide more information, Thanks guys.

edit: Got it working on my windows machine, hope I can get it working on my linux one