Missing PATH to goapp after clean install of Cloud SDK (Version 1.9.2)

[Ralf Rottmann]

Setting up a fully "compliant" Go & App Engine environment is IMHO still more painful than it has to be. Painful might be the wrong word, it causes a level of uncertainty. Maybe somebody can clarify / confirm some aspects, which I still find confusing and see asked by many who are new to GAE and Go. I'd love if Google could maintain a document somewhere, which gets updated on Cloud Platform SDK updates and very clearly outlines what to set up and how.

Before I list my questions, here is the precise version information for my environment, I'm on a Mac, using gae-go version 1.9.2

gcloud -v

Google Cloud SDK 0.9.20

Copyright Google Inc. 2013.

bq 2.0.18

bq-nix 2.0.18

core 2014.04.02

core-nix 2014.03.24

gae-go-darwin-x86_64 1.9.2

gae-python 1.9.2

gae-python-launcher-mac 1.9.2

gcutil 1.15.0

gcutil-nix 1.13.0

gsutil 3.42

gsutil-nix 3.42

sql 2014.03.18

I manually removed any previous version and freshly installed the Cloud SDK. 

Questions / Assumptions:

1.) Path to goapp missing

After a fresh install, the path to goapp is not set, so goapp causes a command not found error.

appcfg.py works, because it lives in google-cloud-sdk/bin/ and that path is set by the install script. Things get more confusing, because goapp exists twice in the SDK, the binary lives in google-cloud-sdk/platform/google_appengine/goroot/bin and a bash script in google-cloud-sdk/platform/google_appengine. Are we supposed to include google-cloud-sdk/platform/google_appengine/goroot/bin into our path? Or should it be /google-cloud-sdk/platform/google_appengine? If so, why does the Cloud SDK install script not automatically handle this? 

2.) GOROOT?

When installing Go, GOROOT points to /usr/local/go. Are we supposed to change this to google-cloud-sdk/platform/google_appengine/goroot? If so, why does the Cloud SDK install script not handle this or at least leave a hint on the console?

3.) GOPATH?

From the docs:

"The GOPATH environment variable is used to specify directories outside of $GOROOT that contain the source for Go projects and their binaries."

Is it therefore correct to assume, that we can keep GOPATH set to just where our very own source code lives? In my environment this would be $HOME/gocode. The reason for not having to add App Engine specifics to GOPATH would be that the sources live inside google-cloud-sdk/platform/google_appengine/goroot and therefore are inside GOROOT and should hence be included automatically.

What do you think? Is all of the above correct? Any tips and hints are greatly appreciated.

--

rottmann.net | Google+ | Twitter | Facebook | LinkedIn

[Glenn Lewis]

I agree that it is currently a painful and confusing experience.  We are working with the Cloud SDK team to improve the situation.

Re #1: I put "google-cloud-sdk/platform/google_appengine" in my path when using the Cloud SDK, but that causes issues for some people, so there is not a good answer to this yet.

Re #2: I don't ever set or mess with GOROOT.  The purpose for the "goapp" bash script wrapper is to correctly configure this and other environment variables for you (before calling the real executable).

Re #3: I leave my GOPATH set to $HOME/go and don't mess with it.  Others have GOPATH set to multiple directories (separated by ":").

I hope that helps.

-- Glenn

--
You received this message because you are subscribed to the Google Groups "google-appengine-go" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kun Li]

I installed the gae_go and related tools from gcloud tool, and I don't even have any of the "goapp", "appcfg.py" and "dev_appserver.py" under "google-cloud-sdk/platform/google_appengine".

I have to download the App Engine Go SDK individually, unzip and use all the tools there.

This is not the first time I run into problem with the toolchain comes with gcloud approach. It's very confusing that it has goapp under the "google-cloud-sdk/bin/" and the only thing it does is to redirect the command request to another goapp under "google-cloud-sdk/platform/google_appengine", and I don't have any "goapp" under this path. it's like a deadend to me.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine-go+unsub...@googlegroups.com.

[Glenn Lewis]

What version of the Cloud SDK did you download?

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.

[Kun Li]

gcloud -v

Google Cloud SDK 0.9.27

app 2014.07.15

app-engine-go-darwin-x86_64 1.9.7

app-engine-java 1.9.7

app-engine-python 1.9.7

app-engine-python-extras 1.9.6

bq 2.0.18

bq-nix 2.0.18

compute 2014.07.15

core 2014.07.15

core-nix 2014.06.17

dns 2014.04.30

gae-go 2014.07.15

gae-go-nix 2014.07.15

gae-python 2014.05.06

gae-python-launcher-mac 1.9.7

gcutil 1.16.3

gcutil-nix 1.16.1

gsutil 4.3

gsutil-nix 4.3

preview 2014.07.15

sql 2014.07.15

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine-go+unsubscribe...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Glenn Lewis]

Hmmm... that's really odd.  I just did a fresh install on Mac OS X, and get this:

$ curl https://sdk.cloud.google.com | bash

...

  [1]  Java

  [2]  Python and PHP

  [3]  Go

  [4]  No App Engine (you can install App Engine tools later)

Please enter your numeric choice (4):  3

...

$ which gcloud

/Users/gmlewis/google-cloud-sdk/bin/gcloud

$ gcloud -v

Google Cloud SDK 0.9.27

app-engine-go-darwin-x86_64 1.9.7

app-engine-python 1.9.7

app-engine-python-extras 1.9.6

bq 2.0.18

bq-nix 2.0.18

compute 2014.07.15

core 2014.07.15

core-nix 2014.06.17

dns 2014.04.30

gae-go 2014.07.15

gae-go-nix 2014.07.15

gae-python 2014.05.06

gae-python-launcher-mac 1.9.7

gcutil 1.16.3

gcutil-nix 1.16.1

gsutil 4.3

gsutil-nix 4.3

sql 2014.07.15

$ which goapp

/Users/gmlewis/google-cloud-sdk/bin/goapp

$ goapp help

Go is a tool for managing Go source code.

...

Can you please try a "gcloud components update" or a fresh install?

-- Glenn

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.

[Kun Li]

It didn't work if I just uninstall some components then reinstall them. It did work when I made a fresh install. Not sure about the reason but thanks!

[lawr...@homeprice.com.hk]

still very painful after 3 years, gcloud sdk is supposed the default tool to work but that doesn't work once you start to import things like "google.golang.org/appengine" . Not even a tutorial is available on this.

[Gregg Murray]

Agree the "getting started instructions on setting up a dev environment for gae and GO is still a complete mess."  There are many many steps missing from the documentation, they assume that if you're using go you have a working knowledge of python which many don't, there is no mention on why all the examples suddenly have "google.golang.org/appengine" instead of "appengine", no clarity on how to set environment variables, path, etc, there's linux exmaples mixed in with the windows instructions, and this entire thing assumes you're an expert on GIT.

[chal...@evernote.com]

On Saturday, April 5, 2014 at 8:58:19 AM UTC-7, Ralf Rottmann wrote:

1.) Path to goapp missing

After a fresh install, the path to goapp is not set, so goapp causes a command not found error.

I also noticed that when I wiped out and rebuilt my dev environment, goapp disappeared. New members to my team are also not able to run goapp.

When I first noticed this, I suspected that gcloud was being groomed to replace goapp, so I investigated how difficult it would be to stop using goapp. There are a few hurdles:

1. There is no replacement for goapp test.

Testing with the system's version of go test can help. But: I've been bitten by code that runs fine in go 1.8 and 1.9, and breaks in appengine go 1.6.

2. gcloud deploy and dev_appserver.py expect a different directory structure.

Compared to goapp deploy, gcloud deploy is much picker about the location of project files. In order to isolate my project from other go code, I set GOPATH to my project root, and then this structure would work under goapp deploy:

* app.yaml

* services

  * www

    * include.yaml

    * main.go

* src

  * my_server_lib

  * other util libs...

However, gcloud deploy does not work with this. It looks like I'm being forced to move main.go and include.yaml to the project root. I'm not sure how to organize and separate the www service from the other services if I do this. I know that the GAE hello world tutorials show that sort of structure, but that's a hello world project with just one service, and I have many other files and folders that need to be at the project root. That means I have lots to do before I can move away from goapp.

In the meantime, it looks like the goapp program is still there in the SDK install, just hiding and not added to the PATH. To make it available again, I made this shell script executable, named it goapp, and put it in my PATH:

#!/bin/bash

gcloud="$(which gcloud)"
[ -L "$gcloud" ] && gcloud="$(readlink "$gcloud")"  # works for regular and brew installs
appdir="$(dirname "$(dirname "$gcloud")")"
goapp="${appdir}/platform/google_appengine/goapp"
python "$goapp" "$@"

You may additionally need to run these:
gcloud auth login
gcloud components install app-engine-go

[Chaim-Leib Halbert]

On 2018-03-01, Homebrew renamed python3 to python, breaking scripts expecting python to be version 2.7, including my goapp script. Here is a fixed version:

#!/bin/bash
gcloud="$(which gcloud)"
[ -L "$gcloud" ] && gcloud="$(readlink "$gcloud")"

appdir="$(dirname "$(dirname "$gcloud")")"
goapp="${appdir}/platform/google_appengine/goapp"

if ! [ -f "$goapp" ]; then
    echo "goapp is not in the Google Cloud SDK libraries." >&2
    echo "Hint: try running this command:" >&2
    echo "" >&2
    echo "    gcloud components install app-engine-go" >&2
fi

# On 2018-03-01, Homebrew renamed python3 to python, breaking scripts that expected
# python to be 2.7. Make sure we are using Python 2.
if [[ "$(python --version 2>&1)" == *' 2.7'* ]]; then
    PYTHON=python
elif type python2.7 &>/dev/null; then
    PYTHON=python2.7
elif type python2 &>/dev/null; then
    PYTHON=python2
elif [[ "$(/usr/local/opt/python@2/bin/python --version 2>&1)" == *' 2.7'* ]]; then
    PYTHON=/usr/local/opt/python@2/bin/python
elif [[ "$(/usr/bin/python --version 2>&1)" == *' 2.7'* ]]; then
    PYTHON=/usr/bin/python
else
    echo "could not find Python 2.7" >&2
    exit 1
fi
"$PYTHON" "$goapp" "$@"