The downloads page <https://cloud.google.com/appengine/docs/standard/go/download> 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 <https://groups.google.com/forum/#!msg/google-appengine-go/sOg4eaEpst0/MqqC4FH4CAAJ> 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). On Sunday, April 9, 2017 at 8:05:47 AM UTC-4, Tim Becker wrote: > > 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 > > On Saturday, 8 April 2017 22:18:15 UTC+2, Adam (Cloud Platform Support) > wrote: >> >> 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. >> <https://cloud.google.com/appengine/docs/standard/go/tools/uploadinganapp> >> 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. >> >> On Saturday, April 8, 2017 at 11:57:29 AM UTC-4, Tim Becker wrote: >>> >>> 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) >>> >> -- 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+unsubscr...@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/8c2ebd5d-7a88-492c-a232-100dca3e9d94%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
