gcloud vs. goapp for GO appengine

1,978 views
Skip to first unread message

Tim Becker

unread,
Apr 8, 2017, 11:57:29 AM4/8/17
to Google App Engine
Sorry if I'm missing something obvious, but it seems that the documenation is very unclear about this and was just recently changed with no clear migration instructions:
  • since recently (~ last week sometime) the prefered way to install Golang support seems to be via the "Google Cloud SDK" (vs the "original App Engine SDK for Go")
  • previously, the `goapp` tool was a central part of my workflow in order to deal with the dependency on the completely outdated 1.6 version of Go required by appengine
  • using gcloud and installing go support via `gcloud components install app-engine-go` gets me two `goapp`s:
    •  ./google-cloud-sdk/platform/google_appengine/goapp
    •  ./google-cloud-sdk/platform/google_appengine/goroot/bin/goapp
  • the first of which is a python script with no executable bit set, and neither of which are in the PATH set up by the install.sh script
  • running, eg. `./google-cloud-sdk/platform/google_appengine/goroot/bin/goapp test` results in the following error:
    • `go: cannot find GOROOT directory: /private/var/folders/bs/nn10qt5j32g25qwgd77wkcyh00d7l1/T/appengine/go_appengine/goroot
Now there are `gopath` and `goroot` dirs in the `plattform/google_appengine` directory and I'm tempted to set the corresponding environment variables to point to those directories, because at least `goroot` seems to have all the necessary appengine dependencies install in it. But this leaves me wondering, where my app should reside. And dealing with appengine/gcloud/whatever it's called today in this manner feels just like "trying out random stuff"

The README contains completely outdated info from 2008. And the online docs only seems to focus on using the "classic" SDK (e.g. https://cloud.google.com/appengine/docs/standard/go/tools/localunittesting/)

Is there any obvious documenation that I'm missing? Am I the only person encountering these problems?


(btw. I'm using OSX)

Adam (Cloud Platform Support)

unread,
Apr 8, 2017, 4:18:15 PM4/8/17
to Google App Engine
You can still keep the standalone SDK installed alongside gcloud and use the goapp workflow if you prefer. The 'goapp' installed by gcloud resides in a directory outside of the PATH on purpose so as not to conflict with the standalone SDK, and is meant to be invoked only by gcloud. The 'goroot' directory is the same goroot that is included in the standalone SDK. It's best not to try and mash parts of the SDKs together or expose internal bits of gcloud and try to use them like the standalone SDK.

The different ways to deploy a standard environment Go app (goapp, gcloud, or appcfg) are given in the documentation Deploying a Go App. As to where your app should reside, you should always keep your app sources outside of the SDK directory tree, so which SDK you use should not matter.

Tim Becker

unread,
Apr 9, 2017, 8:05:47 AM4/9/17
to Google App Engine
Hi Adam,

thanks for the quick & great answers! 

The documentation does provide a bit of guidance of how to use the three (!) different tools that may be used to deploy, but it leaves me confused as to which method is prefered, or what benefits of one method compared to the others is. I hope the following doesn't seem to whiny, but just some observations that are still fresh in my mind in the hope of helping improve the docs:

> You can still keep the standalone SDK installed alongside gcloud and use the goapp workflow if you prefer. 

At the end of the `install.sh` routines of `gcloud`, one is explicitly encouraged to purge existing SDK intallations as not to conflict... Also, the standalone SDK is not available in the latest version (1.9.48 vs. 1.9.50 installed with gcloud) leaving me weary of conflicts.

> The 'goapp' installed by gcloud resides in a directory outside of the PATH on purpose so as not to conflict with the standalone SDK, and is meant to be invoked only by gcloud. 

From using goapp previously, it seemed `goapp` was intended to be a replacement for all `go` tool invocations. `gcloud` takes care of deployment, but that leaves me unsure what to do about `goapp test|get|install` etc. The `gcloud` installation instructions (https://cloud.google.com/appengine/docs/standard/go/download) mention you should install Go 1.6, so perhaps, the goapp isn't necessary. But, a.) installing 1.6 is not actually  necessary as 1.6 seems to come together with the app-engine-go component and b.) it offers no guidance of how to install 1.6 and a newer version in parallel. As 1.6 is so outdated that it's not even presented among he standard downloads in the Go download archive page, I think it's safe to assume that many developers will not want to use it as their default Go SDK.

Again, hope I'm not being to negative and thanks once more for your support!
    -tim

Adam (Cloud Platform Support)

unread,
Apr 10, 2017, 4:26:27 PM4/10/17
to Google App Engine
The downloads page actually does say "The preferred tooling for managing your App Engine applications in Go is now the Google Cloud SDK'. This seems to be further reinforced by the fact that the standalone SDK is a few version behind, which I didn't notice before. 

I see that gcloud does nag about specifically 'dev_appserver.py' and 'endpointscfg.py' being in your path when you run 'gcloud components update'. To avoid conflicts by invoking the older versions of these tools, it should be sufficient to keep the Cloud SDK first in your $PATH. 

Regarding Go 1.6, this is the version the 'goapp' toolchain is based on as well as the version used by the production runtime (Go 1.8 on GAE is coming soon though). There's no clean way to run different Go versions in parallel (I use a symlink that switches between two different install roots) so it would be difficult to document (though that's not to say there isn't room for improving the docs).

Michael Amie

unread,
Apr 25, 2017, 11:01:19 AM4/25/17
to Google App Engine
Tim,

You are not insane. I have noticed this as well w/ respect to the missing executable bit set on at least one of the goapps (and if I recall correctly, when I looked into this a month or so ago), several other scripts / binaries weren't set to executable as well, post-installation.

As you mention, I got the impression the stand-along "go SDK" was being phased out / deprecated and this was getting rolled into the cloud SDK as a module / component for it.

It seems like they didn't test the new installer or something before rolling it out, and based on the combo of 1. The broken install and 2. The doublespeak of the documentation, I'd wager there is some sort of miscommunication or something between teams / departments going on right now about what's going on during this transition.

I'd love to see Google actually get all their documentation updated / synced with the One True New Way and it would be good if they tried running this new installer on a few Mac OS versions to see if it actually works.

Thanks,
Michael

Justin Beckwith

unread,
Apr 25, 2017, 12:46:26 PM4/25/17
to google-a...@googlegroups.com, Brett Johnson
Hey folks,
Apologies for the confusion.  Here's what's happening.

We are trying to move towards a single Cloud SDK install.  At the same time, we're trying not to break the existing App Engine SDK downloads.  We are headed towards a future (not far away) where everything gets wrapped up into https://cloud.google.com/sdk/.  Instead of having separate SDKs for Go/Python/Java/PHP, we want one toolchain.

We are moving towards tooling consistency.  The goal is to make `gcloud app deploy` work for each language supported by App Engine.  With the exception of Java, we're mostly there.  You should be able to use `gcloud app deploy` and `dev_appserver.py .` instead of `goapp update ` or `goapp serve`.

I'm interested in getting some feedback on this approach. Do you feel like `gcloud app deploy` and `dev_appserver.py .` are enough?  Or are there other reasons you want to keep using `goapp`?

Is this just a matter of unclear documentation?

Thanks!


--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/abb82812-08a4-4bec-af3c-4bf7bac25e58%40googlegroups.com.

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



--

Justin Beckwith | Google Cloud Platform | @justinbeckwith | http://jbeckwith.com

Wilson MacGyver

unread,
Apr 25, 2017, 1:42:02 PM4/25/17
to google-a...@googlegroups.com, Brett Johnson
I'm concerned about the one tool fits all approach. It'd be one thing of the "single tool" gcloud is just a thin wrapper to automatically download and configure each component as needed. What I'm afraid of is unnecessary dependency. Ie, the latest go GAE sdk is being hold up by the latest gccloud release. 

There are some of us that only use GAE, and has no interest using the rest GC service such as GKE, GCE, etc. I've been very happy with the java tool chain where it integrate perfectly into existing JVM build tools via plugins for mvn and gradle. I'm not sure what gcloud tool brings to the table.

If there are very few of us that only uses GAE. or that google doesn't really want us to only use GAE, I understand. But forcing me to use gcloud instead of say a gradle/mvn plugin feels like just more moving parts to me.

with go, I'm a bit more desperate. I prefer the goapp approach, but given that go version on GAE is so behind that if gocloud is the 'only way' to make 1.8 happen faster, then I'll learn to deal with it.


for me, up till now Google cloud's strength has been a much more unix like experience. You use gsutil if you want to deal with cloud storage, goapp for GAE-go, etc etc. I'm a bit surprised to see google moving toward the aws where you use aws-cli for everything.

Just my 2 cents



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



--
Omnem crede diem tibi diluxisse supremum.

Justin Beckwith

unread,
Apr 25, 2017, 1:52:22 PM4/25/17
to google-a...@googlegroups.com, Brett Johnson
Great feedback!  To a few points:

I've been very happy with the java tool chain where it integrate perfectly into existing JVM build tools via plugins for mvn and gradle. I'm not sure what gcloud tool brings to the table.

I should have mentioned this - those aren't going anywhere.  All of the Maven/Gradle/IntelliJ/Eclipse/VS stuff will continue to be distributed on it's own.  

I prefer the goapp approach

Interesting.  Is this just about the single tool philosophy, or is there a specific thing goapp does better than gcloud?  

Thanks! 

 

On Tue, Apr 25, 2017 at 10:41 AM, Wilson MacGyver <wmac...@gmail.com> wrote:
I'm concerned about the one tool fits all approach. It'd be one thing of the "single tool" gcloud is just a thin wrapper to automatically download and configure each component as needed. What I'm afraid of is unnecessary dependency. Ie, the latest go GAE sdk is being hold up by the latest gccloud release. 

There are some of us that only use GAE, and has no interest using the rest GC service such as GKE, GCE, etc. I've been very happy with the java tool chain where it integrate perfectly into existing JVM build tools via plugins for mvn and gradle. I'm not sure what gcloud tool brings to the table.

If there are very few of us that only uses GAE. or that google doesn't really want us to only use GAE, I understand. But forcing me to use gcloud instead of say a gradle/mvn plugin feels like just more moving parts to me.

with go, I'm a bit more desperate. I prefer the goapp approach, but given that go version on GAE is so behind that if gocloud is the 'only way' to make 1.8 happen faster, then I'll learn to deal with it.


for me, up till now Google cloud's strength has been a much more unix like experience. You use gsutil if you want to deal with cloud storage, goapp for GAE-go, etc etc. I'm a bit surprised to see google moving toward the aws where you use aws-cli for everything.

Just my 2 cents


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

Wilson MacGyver

unread,
Apr 25, 2017, 2:07:26 PM4/25/17
to google-a...@googlegroups.com, Brett Johnson
ah ok. I'm glad to hear mvn/gradle plugins aren't going anywhere. seamless integration with the ecosystem's popular build system is something I've always liked about the GAE approach.


as for goapp vs gcloud, currently I'm concerned about reproducible build. goapp is a single tool with its own go tool chain, I don't have to worry about "which version of go to use for what". this causes issue to be sure, 3rd party packages using context is the big sore point.

the gcloud way, requires you to install gcloud, and then your own go toolchain, which currently you can't use anything higher than 1.6. This gives me pause. Since there is an external go toolchain that I have to install and yet have to make sure I don't upgrade it to a version that causes issues. Right now it's bad, when GAE 1.8 comes out we'll have a brief "all is right in the world because it's 1.8 everywhere".

But when GAE finally hits 1.8. what happens when go 1.9 comes out? Am I still going to be in a situation where I have to install 1.8 for gcloud until such time gcloud moves to 1.9?

and then there is also the issue that we use go outside of GAE. Those we aggressively upgrade to the latest go release. Using gcloud means we'll more likely than not, having to have 2 sets of go toolchain installed.

where as goapp, I just download the latest one, it's a sandbox that I won't need to touch for any non-GAE stuff.

Thanks,




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

David Komer

unread,
Apr 25, 2017, 4:10:59 PM4/25/17
to Google App Engine, bre...@google.com
Fwiw I just jumped onto windows and can't remember how I had things setup on my osx box :\

To get things working as expected in VSCode, and without installing go1.6 along with google cloud sdk (e.g. goapp), I ended up having to do the following:

1) Copy goapp.bat to go.bat (maybe a shortcut would work, but didn't want to chance it)

i.e.
FROM C:\Users\[USERNAME]\AppData\Local\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\goapp.bat 
TO C:\Users\[USERNAME]\AppData\Local\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\go.bat

2) Copy goapp.exe to go.exe (also, didn't want to chance a shortcut)

i.e.
FROM C:\Users\[USERNAME]\AppData\Local\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\goroot\bin\goapp.exe
TO C:\Users\[USERNAME]\AppData\Local\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\goroot\bin\go.exe

3) Set "go.goroot" in settings.json to to C:/Users/[USERNAME]/AppData/Local/Google/Cloud SDK/google-cloud-sdk/platform/google_appengine/goroot

(it wasn't picking it up right from env settings)

All in all this seems pretty convoluted... maybe I'm missing something, but from a pure practical perspective, the ideal for me would be to have the appengine bundle work just like a regular go installation, and to simply switch versions by changing the GOROOT and GOPATH settings. Due to the above - seems like that's absolutely possible if the filenaming structure of goapp were more in line with what's expected in GOROOT
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
--

Justin Beckwith | Google Cloud Platform | @justinbeckwith | http://jbeckwith.com

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.



--
Omnem crede diem tibi diluxisse supremum.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.



--

Justin Beckwith | Google Cloud Platform | @justinbeckwith | http://jbeckwith.com

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.

Michael Amie

unread,
Apr 26, 2017, 12:30:10 AM4/26/17
to Google App Engine, bre...@google.com
For what it's worth, I like the move to roll everything into a set of modules for the Cloud SDK you install via it vs separate random tarballs you download, but the problem was I could never figure out how to get the new stuff working, while all the old stuff works at was at least matching a lot of the documentation. It made it seem like the new stuff was still some weird beta software not meant for general use.

To the uninitiated, it seemed like in the newer package there were duplicate commands with the same file names that were, confusingly, , in some cases, scripts and in other cases binaries. And many of them (on Mac OS) did not have file permissions you would have expected (at least least at the time, although I am still seeing this with one binary even now). I would expect all binaries and all scripts to be chmod +x out of the box, for example, in *NIX parlance.

To be honest though, it would be best if some kind of unity could occur between "go get" and all the Google App Engine stuff for installing modules. If Google owns both goland and app engine, why is it treated separately? You are in the position to make it all one unified system.

In the *NIX world (even outside of Mac OS) there's already the weirdness between distro packaging vs your programming / scripting language of choice's packaging (concrete examples: easy_install / pip, npm, whatever the hell ruby uses, CPAN, etc). So at the very least it would be nice if there was some degree of parity between Golang's core package manager and App Engines. But for me, even that is far reaching. The least that could happen would be that you are able to:

1. Install the Google Cloud SDK
2. Install your language of choices App Engine modules via its package manager
3. It's then obvious what command you run to spin up a local dev server and its also obvious what command you run to push your local stuff to a new app engine instance
4. The toolchain tree should not be convoluted insofar as where all the executables are so you can source that dir properly in your PATH env vars
5. The installer should have correct executable permissions for any and all scripts / binaries out of the box

Again, sorry if I'm an idiot and have overlooked something, but I've also seen plenty of other projects that I'm not certain were backed by any corporations at all that had obvious setups and HOWTOs in place for getting started with the bare minimum.

Thanks,
Michael
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.

Tim Becker

unread,
Apr 26, 2017, 3:28:27 AM4/26/17
to Google App Engine, bre...@google.com
FWIW, this thread has made made feel less alone in my confusion conerning the goapp/new tooling problem. Thanks to everyone sharing their views and especially Adam and Justin from the appengine team, having you guys here and answer in a timely and knowledgeable really helps alleviate my concerns.

The central issue is lack of documentation. Concrete steps are described well, but the underlying principles aren't discussed, e.g. "you can use the gcloud tool or goapp" but it's unstated why you would prefer one over the other. The implicit assumption that both may be used in parallel is never mentioned. The documentation also doesn't leave me in a position to make an informed decision about how to proceed, or even which underlying issues affect my choice (Go 1.6 support...)

This may be a quirk for me, but I'm very concerned about writing "appengine" code vs. writing Go. Appengine should ideally be one possible deployment plattform. The fact that I have to provide facilities to isolate the custom http client and have to find a way to deal with having to drag around a custom context already irks me. Necessitating custom build-tooling makes the plattform seem even more intrusive. In an ideal world, I would have been able to just use a stock `go` binary (like the java people can just continue to use maven or gradle). 



To me the issues boiled down to the fact that vanilla 1.6 SDK support is not trivial to install in parallel to a current SDK (lack of support for older versions extends down to the documentation level: no older SDK docs are online and it's hard to figure out which features are not availables as there's no indication of new/deprecated methods, anlagog to javadocs @since and @deprecated. E.g. I spent a considerable amount of time trying to figure out why using xml.Encoder's Indent() broke the build ... ) 

`goapp` to me seems like a good comprise as it just wraps the standard `go` commands for day-to-day development use. I don't want to learn anything new to use appengine, or at least not more than a bullet list of considerations. `goapp` also conventiently  includes 1.6 everything; I don't have to change or uninstall anything or create an isolated vm. 

The following would be helpful additions to the documentation (for me):

- provide a bit of general abstract background about appengine and it's restrictions and how go fits in / go's limitations
- even if there are numerous possible workflows, provide at least one concrete example of the 'intended' workflow, including installing a parallel 1.6 go (or using the one provided by the SDK), how to set up the environment of $GO... variables, how to install libs, how to run unit tests ... This would work well with the opinionated nature of Go in general, i.e. there is an intended and correct way of doing things and it's explicit (gofmt).
- provide Godoc for the entire appengine api including the 1.6 SDK (and in the standard godoc format!)

Ideally,  open the discussions of the go appengine development team to the outside world, in the same manner that most of the core go development takes place in the open. You guys have obviously put a lot of though into these issues already, and having these discussions out in the open would help understand the implicit assumptions without having to officially document them.

Thanks!
    -tim 







Michael Amie

unread,
Apr 26, 2017, 9:58:18 AM4/26/17
to Google App Engine, bre...@google.com
It occurred to me with a fresh mind this morning that since the App Engine SDK includes a lot of general purpose utilities, many of which seem to be Python scripts, it would make absolutely no sense for those to be installed via "go get" since that is intended to install Go modules, and nothing else. So I'd like to retract / withdraw that portion of my 2nd post. Sorry, I haven't been using this stuff much the last month or so. This weekend, when I have a few hours, I can revisit the current state of the install process and the "getting started" documentation and give more specific info, although pretty much everything Tim has brought up so far in his posts seems to mirror what has confused me.

Thanks,
Michael

Simon Green

unread,
Apr 27, 2017, 5:33:18 PM4/27/17
to Google App Engine, bre...@google.com
Something is missing 'docs' wise. It's very unclear what you are meant to use tools wise (this is a perpetual issue with Google cloud)

Every few weeks I figure I should be using gcloud but whenever I try it doesn't work and there are no docs to explain how to set it up. AFAIK it's all running, I use it for other things, it doesn't work for Go and never has. It tells me extra files exist and should be removed - if I remove them then even more things stop working.

goapp was simpler / easier and I still use it because it works and I can't keep spending time trying to figure out gcloud.

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

Steffen N

unread,
Apr 30, 2017, 11:28:15 AM4/30/17
to Google App Engine
Hey Tim, no you are not the only one. Im facing the same issues. Im also having 2 'goapps' just like yours and when I run 'goapp serve' inside a project folder where I have my app.yaml it says permission denied. 

Lawrence Mok

unread,
Jun 30, 2017, 9:04:44 AM6/30/17
to Google App Engine
documentation is always very unclear and even I had used AppEngine for years I had to spend hours looking around for solutions everytime something is changed.

This time I switch from using goapp tools to gcloud then things start to break again.

For example, with gcloud there's no clear instruction how to get the dependency libraries where previously we used goapp get.

And deploying apps result in errors like:

C:\github\xxxxxxxx\xxxxxxx>gcloud app deploy --no-promote --project xxxxxx
ERROR: (gcloud.app.deploy) Staging command [C:\gcloudsdk\google-cloud-sdk\platform\google_appengine\goroot-1.6\bin\go-app-stager.exe C:\github\xxxxxxx\xxxxxxxxx\app.yaml c:\users\xxxxxxxx\appdata\local\temp\tmpcg1lmc\tmpshymkv] failed with return code [1].

------------------------------------ STDOUT ------------------------------------
------------------------------------ STDERR ------------------------------------
2017/06/30 14:50:01 failed analyzing C:\github\xxxxxxxxx\xxxxxxxx: cannot find package "golang.org/x/net/context" in any of:
        ($GOROOT not set)
        ($GOPATH not set)
GOPATH:
--------------------------------------------------------------------------------

chal...@evernote.com

unread,
Oct 2, 2017, 4:02:58 PM10/2/17
to Google App Engine
My main concern is, what is going to happen to goapp test? This is a critical part of our toolchain that tests our code under appengine go (as opposed to non-appengine go, which I installed via brew). I am not seeing a documented replacement for this tool anywhere.

As a temporary hack to keep access to goapp, I created a wrapper script to run the goapp script hidden inside the google-cloud-sdk distro. See https://groups.google.com/forum/#!topic/google-appengine-go/h4GKKDAskxY

Other than that, I am currently working to convert our project structure to the new, more stringent one enforced by gcloud. The conversion is not complete, and is rather involved. Interestingly, dev_appserver.py and goapp deploy are more lax about project structure than gcloud deploy, in that before, the app entry point (main.go) is was allowed to be inside the GOPATH. I therefore set GOPATH to the repo root in order to exclude external disturbances from our build, and put main.go inside a sibling to the src directory. This breaks under gcloud deploy, since main.go is not allowed to be anywhere under the GOPATH. (I had to read the SDK source code to discover this.)

To become compliant with gcloud expectations, I am working on relocating main.go outside of the GOPATH, while keeping both a gopath directory and main.go inside the same repository for simplicity (I don't want to have to keep an app repo and our private library repos in sync).

However, once that is done, I will still need a fast way to run unit tests under appengine go before deploying. I hope there are plans to keep the functionality of goapp test.

On Tuesday, April 25, 2017 at 9:46:26 AM UTC-7, Justin Beckwith wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.

chal...@evernote.com

unread,
Mar 8, 2018, 3:25:04 PM3/8/18
to Google App Engine
I discovered that currently, gcloud does not support vendored dependencies, so efforts to restructure our repository have stopped. We are still using my goapp script to do deploys.

Recently, on 2018-03-01, Homebrew renamed python3 to python, breaking my goapp script, so here is a fix:
#!/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 at python, python2.7, python2, or /usr/bin/python" >&2
   
exit 1
fi
"$PYTHON" "$goapp" "$@"
Reply all
Reply to author
Forward
0 new messages