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 On Tuesday, April 25, 2017 at 9:46:26 AM UTC-7, Justin Beckwith wrote: > > 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! > > > On Tue, Apr 25, 2017 at 1:21 AM, Michael Amie <michae...@gmail.com > <javascript:>> wrote: > >> 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 >> >> On Saturday, April 8, 2017 at 8:57:29 AM UTC-7, 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-appengi...@googlegroups.com <javascript:>. >> To post to this group, send email to google-a...@googlegroups.com >> <javascript:>. >> 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 >> >> <https://groups.google.com/d/msgid/google-appengine/abb82812-08a4-4bec-af3c-4bf7bac25e58%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > > Justin Beckwith | Google Cloud Platform | @justinbeckwith > <http://twitter.com/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-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/8aa60452-3cb3-4a31-af48-3255c13f6456%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
