When installing Atom via flatpak, go-plus won't find go

[Znert]

Prerequisites

• [ ] Have you tried launching atom . from the terminal in your project's directory?
• [x] Have you verified the output from go env is correct? If it is, please include the output in this issue.
• [x] Have you updated Atom to the latest version?
• [ ] Have you tried using Atom Beta, which can be run side-by-side with Atom Stable? Is the behavior the same, or different?
• [x] Have you updated your Atom packages to the latest versions?
• [x] Have you read the FAQ?
• [x] Have you searched the issues to see if others are experiencing the same issue?

Description

As there currently are not issue listed for flatpak, I would like to report the issue myself.

flatpak, quite similary so snap I suppose, runs Atom in an isolated sandbox. Therefore the go binary is not accessible by just calling go in the terminal.

There currently is a workaround, which I describe in the flatpak issue-tracker: https://github.com/flatpak/flatpak/issues/2126

tl;dr: Set flatpak to include host's filesystem and add the go binary file to the PATH.

Output from atom -v && apm -v

Atom : 1.30.0 Electron: 2.0.5 Chrome : 61.0.3163.100 Node : 8.9.3 apm 1.19.0 npm 3.10.10 node 6.9.5 x64 atom 1.30.0 python 2.7.12 git 2.9.3

Output From go env

GOARCH="amd64" GOBIN="" GOCACHE="/home/znert/.var/app/io.atom.Atom/cache/go-build" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/home/znert/go" GOPROXY="" GORACE="" GOROOT="/run/host/usr/local/go" GOTMPDIR="" GOTOOLDIR="/run/host/usr/local/go/pkg/tool/linux_amd64" GCCGO="gccgo" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build546450394=/tmp/go-build -gno-record-gcc-switches"

Steps to Reproduce

1. Install Atom via flatpak.
2. Install go-plus

Expected Behavior

go-plus should find go

Actual Behavior

go-plus cannot find go, as it is not in the PATH (per default).

Therefore I would suggest that go-plus should allow setting the path to the go binary to also allow custom installation directories of go and/or include people who (for some reason) do not want the go binary to be in the PATH variable.

Bonuspoints if go-plus could inform the user if it can't find go, that he/she might has to set the path manually (with a hint for flatpak users maybe?) :)

[zmb3]

Suppose we did allow setting the path to the go binary. What would you do about all of the other tools that this extension depends on (goimports, godef, gogetdoc, gorename, guru, gometalinter, etc. etc.)?

[Znert]

Given that all binaries of the dependencies are under go/bin I don't see a reason not to allow just defining the path where all the binaries actually are...

I'm not familiar on how all of that works, so let me write it in somewhat pseudo-code here:

options.depPrefix = ''; // Setable in the options

// calling goimports
exec(options.depPrefix + 'goimports');

That way, if the user does not set the prefix, it'll just call goimports, relying on the PATH env variable. If it is set, however, to say '/bin/go/bin/' it will call it with the absolute path attached.

Of course you would have to ensure, that the prefix does not allow the user to execute arbitrary code, but you get the gist.

[zmb3]

All binaries are not under go/bin. Many of them, but not all, are under $GOPATH/bin - but even that may change in the near future as the community adopts modules and moves away from GOPATH.

Definitely open to help make things work for you, but I don't have enough (any) experience with flatpak to know what is going to work best. Would be happy to review a PR if you want to work through it. The package is going to need to execute the go tool as well as a number of binaries at a configurable location. It may also need to go get these tools, so this path must be writable.

[Znert]

It might sound like a lame excuse, but given that university just started again, and I also have to work part-time, I might not find the time to read into the code and understand how everything works... I will try to free some time for it, however.

As a quick info to flatpak, if you call flatpak-spawn within the sandbox, you can execute code as if Atom were running on the host directly. So instead of calling go you would call flatpak-spawn go, for go env flatpak-spawn go env etc. Sadly documentation is rather sparse on it, as it apparently is a feature newly added in 1.0.

On a side note, I also reported the issue to flatpak - as mentioned - and they informed me that tools for exactly such cases will be developed, but I must wonder how they will keep the sandbox secure/sandboxed if you can then execute arbitrary (host-)code anyways...

[dhaavi]

I opened an issue yesterday that is quite similar, but reversed, trying to containerize go, not atom: #832

The problem is the same, go-plus does not find go, albeit go and all tools (wrappers of them) being in the PATH.

[KhalilSantana]

I've been struggling with this for a while, this is my solution (tested on Antergos):

First lets set $GOPATH, this will be used to download go-plus' dependencies: export GOPATH="$HOME/Downloads/Bin/go" I recommend adding this to your .bashrc or equivalent, but for testing purposes you don't need to do it.

Then you must install the flatpak'd Golang SDK, in my case I'm using a system-wide install: sudo flatpak install flathub org.freedesktop.Sdk.Extension.golang (I recommend using the 18.08 branch)

Then you must edit the $PATH variable inside the sandbox to include the flatpak'd Golang SDK we've just installed before: sudo flatpak override io.atom.Atom --env=PATH="/app/bin:/usr/bin:/usr/lib/sdk/golang/bin"

Now try opening Atom: flatpak run io.atom.Atom

Enjoy!