Re: [google-appengine] Re: gcloud vs. goapp for GO appengine

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/ba

Re: [google-appengine] Re: gcloud vs. goapp for GO appengine

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 a

[google-appengine] Re: gcloud vs. goapp for GO appengine

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 instruc

[google-appengine] Re: gcloud vs. goapp for GO appengine

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. On Saturday, April 8, 2017 at 5:57:29 PM UTC+2, Tim Becker wrote: > > Sorry if I'm

Re: [google-appengine] Re: gcloud vs. goapp for GO appengine

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,

Re: [google-appengine] Re: gcloud vs. goapp for GO appengine

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

Re: [google-appengine] Re: gcloud vs. goapp for GO appengine

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

Re: [google-appengine] Re: gcloud vs. goapp for GO appengine

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 lo

Re: [google-appengine] Re: gcloud vs. goapp for GO appengine

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 wo

Re: [google-appengine] Re: gcloud vs. goapp for GO appengine

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

Re: [google-appengine] Re: gcloud vs. goapp for GO appengine

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 th

Re: [google-appengine] Re: gcloud vs. goapp for GO appengine

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 r

Re: [google-appengine] Re: gcloud vs. goapp for GO appengine

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 htt

[google-appengine] Re: gcloud vs. goapp for GO appengine

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

[google-appengine] Re: gcloud vs. goapp for GO appengine

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 behin

[google-appengine] Re: gcloud vs. goapp for GO appengine

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 th

[google-appengine] Re: gcloud vs. goapp for GO appengine

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'