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" "$@"
On Monday, October 2, 2017 at 1:02:58 PM UTC-7, chal...@evernote.com wrote:
>
> 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:
>>
>> 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>
>> 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.
>>> To post to this group, send email to google-a...@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
>>>
>>> <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/16102f08-c935-40e1-b9df-d85571f323c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
