Use different tool to "go build" per project

[amoghe]

When working on golang projects that are meant to run in Google AppEngine (GAE), these projects must be compiled (and tested) with tools that ship with the SDK, namely goapp. This is a wrapper around the go binary, so it is almost fully compatible with go (i.e. you can run goapp <CMD> instead of go <CMD>, e.g. - goapp test instead of go test)

One way to work with this project in Atom (using go-plus) would be to add a symlink called "go" to point to the "goapp" binary, and set the installation path variable to the dir containing this symlink (thereby "fooling" the plugin to use the wrapper tool). However I believe this would persist the change for all projects (even non GAE ones).

Do you have suggestions on how I could make this change on a per-project basis? (Or maybe have this plugin detect GAE projects (using the index.yaml file in the top dir), and invoke the goapp tool instead (which is assumed to be in $PATH, or discoverable in the same way the go bin is detected).

[joefitzgerald]

Is there any way to detect that an app is a GAE app? A file in the root of the import path?

[amoghe]

I guess this ticket boils down to 2 items:

1. Question: per project settings for this plugin?
2. Request: support GAE projects (detecting them is straightforward, the tool change is also seemingly straightforward).

[amoghe]

Is there any way to detect that an app is a GAE app?

Yes, the top level dir will contain a file named app.yaml

[amoghe]

... and invoke the goapp tool instead of...

This would work for for vet, build and test.

golint and goimports seem to work fine without any modifications.

[rest of comment redacted]

[derekperkins]

Yes, the top level dir will contain a file named app.yaml

@amoghe That's not necessarily true. If you are using modules, they could be nested as in the image below (which is the recommendation from the Google App Engine team).

[joefitzgerald]

It seems so ridiculous that GAE requires different tools because of its restricted runtime environment. Has anyone got access to the new GCE alpha (https://cloud.google.com/container-engine/)? It feels like the fix to this is just to not use a PaaS that requires goapp 😉. I believe GCE will allow you to use the normal go binary distribution (?).

Now, a cynic would say that I'm saying this because my day job is focused on Cloud Foundry, but seriously - run your go apps in containers rather than using GAE 😄.

Sorry, just had to get that off my chest.

TL;DR; Happy to accept a PR to fix this!

[campoy]

Hi Joe,

First of all thanks for this amazing package! I recently started using atom.io and I gotta say one of the reasons was this :)

I am a Developer Advocate for the Go team and the Google Cloud Platform so we could say that if you have some complaints I'm happy to be your point of contact!

I'll try to try to fix this and send a PR as soon as I have some time unless someone has been working on it.

Cheers, and thanks again for this great tool!

Francesc

[joefitzgerald]

Hey @campoy, thanks for the help! Feel free to join the Gitter room if you'd like to discuss in more detail.

[atrauzzi]

@campoy @joefitzgerald - Just been dipping my toes in go development on app engine and using the atom editor.

Unfortunately, every time I try to import from appengine, I get Cannot find package "appengine"...

I'm fairly certain this is related to everything I'm reading here, but I'm wondering if there's been any progress since January on these issues? I'd love to be able to do go development with code assist targeting app engine (rather than requiring billing for the project I'm working on to use containers). But what I'm encountering right now sours me on the whole thing!

[campoy]

You should consider using the new appengine packages

https://godoc.org/google.golang.org/appengine

That will solve all your problems :)

On Sat, Oct 17, 2015 at 7:27 PM Alexander Trauzzi notifications@github.com
wrote:

@campoy https://github.com/campoy @joefitzgerald
https://github.com/joefitzgerald - Just been dipping my toes in go
development on app engine and using the atom editor.

Unfortunately, every time I try to import from appengine, I get Cannot
find package "appengine"...

I'm fairly certain this is related to everything I'm reading here, but I'm
wondering if there's been any progress since January on these issues? I'd
love to be able to do go development with code assist targeting app engine
(rather than requiring billing for the project I'm working on). But what
I'm encountering right now sours me on the whole thing!

—
Reply to this email directly or view it on GitHub
#76 (comment)
.

[joefitzgerald]

@campoy would this allow someone to stop using goapp and use go as usual?

[campoy]

That's a good question ... the answer is no.

goapp is still responsible for parsing app.yaml and other config files and
to start the webservers.
this will be the case even when we move to managed VMs, which are based on
dockerfiles.

On Mon, Oct 19, 2015 at 11:10 AM Joe Fitzgerald notifications@github.com
wrote:

@campoy https://github.com/campoy would this allow someone to stop
using goapp and use the go as usual?

—
Reply to this email directly or view it on GitHub
#76 (comment)
.

[atrauzzi]

Hm, I'm still noticing an issue where goapp complains about duplicate definitions. Almost like as if it's got two GOPATHs?

[campoy]

Completely unrelated issue here.

If there's more than one way to access an imported package goapp will
complain.
Try moving your app.yaml out of the root directory. Check this repo out
https://github.com/campoy/todo for an example

On Mon, Oct 19, 2015 at 11:20 AM Alexander Trauzzi notifications@github.com
wrote:

Hm, I'm still noticing an issue where go complains about duplicate
definitions. Almost like as if it's got two GOPATHs?

—
Reply to this email directly or view it on GitHub
#76 (comment)
.

[atrauzzi]

@campoy Thanks for the insight. Based on that, is there any way for me to bundle app.yaml as part of the directory? Reason being, that's obviously my .git root... ;)

[derekperkins]

@joefitzgerald For everything related to go-plus, using the new appengine packages completely eliminates the need for goapp.

[campoy]

Wooohoo!

On Mon, Oct 19, 2015 at 11:46 AM Derek Perkins notifications@github.com
wrote:

@joefitzgerald https://github.com/joefitzgerald For everything related
to go-plus, using the new appengine packages completely eliminates the need
for goapp.

—
Reply to this email directly or view it on GitHub
#76 (comment)
.

[joefitzgerald]

@derekperkins wonderful! So you're saying that https://github.com/joefitzgerald/go-runtime/blob/e5534d1e72a3b410452d8e863925f2b7f8096dd5/lib/locator.js#L23 is effectively not required anymore?

As you can see I'm going through a major rewrite of go-plus, and this will be a helpful simplification 😄.

[campoy]

I'm saying that that fix is not needed for everybody using the new packages.
And the only reason to keep using the old packages is because your codebase
is already big enough that a big rewrite would be painful.

So yeah, probably not many go-plus users care about it anymore :)

On Mon, Oct 19, 2015 at 12:07 PM Joe Fitzgerald notifications@github.com
wrote:

@derekperkins https://github.com/derekperkins wonderful! So you're
saying that
https://github.com/joefitzgerald/go-runtime/blob/e5534d1e72a3b410452d8e863925f2b7f8096dd5/lib/locator.js#L23
is effectively not required anymore?

As you can see I'm going through a major rewrite of go-plus, and this will
be a helpful simplification [image: 😄].

—
Reply to this email directly or view it on GitHub
#76 (comment)
.

[atrauzzi]

Wait, so if I am starting a new project, what do I have to do?

[joefitzgerald]

@atrauzzi so if I'm reading this right, start your new project, use the new library that @campoy linked to, but use go and not the goapp exectuable to actually run go build, go test, etc.

[campoy]

The plan is:

• import "google.golang.org/appengine"
• ?
• profit

(https://www.youtube.com/watch?v=tO5sxLapAts)

[atrauzzi]

@campoy Haha, I meant for the local development server. What do I run to try my app out from inside of my package?

[campoy]

No, use goapp, not go.

On Mon, Oct 19, 2015 at 12:14 PM Joe Fitzgerald notifications@github.com
wrote:

@atrauzzi https://github.com/atrauzzi so if I'm reading this right,
start your new project, use the new library that @campoy
https://github.com/campoy linked to, but use go and not the goapp
exectuable to actually run go build, go test, etc.

—
Reply to this email directly or view it on GitHub
#76 (comment)
.

[atrauzzi]

Okay, so when I use goapp though, I'm getting the error of duplicated names mentioned earlier. Is there no way I can bundle app.yaml with my sources?

[campoy]

Expanded answer:

1. write some App Engine app:

package app

import (
    "fmt"
    "net/http"

    "google.golang.org/appengine"
    "google.golang.org/appengine/log"
)

func init() {
    http.HandleFunc("/", handler)
}

func handler(w http.ResponseWriter, r *http.Request) {
    ctx := appengine.NewContext(r)
    log.Infof(ctx, "handler called")
    fmt.Fprintln(w, "hello!")
}

1. write your app.yaml

runtime: go
api_version: go1

handlers:
- url: /
  script: _go_app

1. serve locally:

$ goapp serve

[campoy]

@atrauzzi: create a new directory app where you'll have your app.go and app.yaml files which then import other packages.

[atrauzzi]

@campoy Is this directory outside of my GOPATH?

[campoy]

no

On Mon, Oct 19, 2015 at 12:24 PM Alexander Trauzzi notifications@github.com
wrote:

@campoy https://github.com/campoy Is this directory outside of my
GOPATH?

—
Reply to this email directly or view it on GitHub
#76 (comment)
.

[campoy]

GOPATH

• github.com
  • username
    • reponame
      |- app
      | |- app.yaml
      | - app.go
      • pkg
        |- other packages imported by app.go

On Mon, Oct 19, 2015 at 12:25 PM Francesc Campoy Flores campoy@google.com
wrote:

no

On Mon, Oct 19, 2015 at 12:24 PM Alexander Trauzzi <
notifications@github.com> wrote:

@campoy https://github.com/campoy Is this directory outside of my
GOPATH?

—
Reply to this email directly or view it on GitHub
#76 (comment)
.

[atrauzzi]

Oh, you can do that structure even inside of a package? Well isn't that fancy! #TIL

[derekperkins]

@joefitzgerald I don't think you should remove that yet. I don't have any inside info, but from a heavy appengine user, here's the current situation in a nutshell:

• App Engine has their classic setup that works with either "appengine/..." or "google.golang.org/appengine/...". It runs on an internal container implementation with a lot of restrictions.
• They also have their Managed VM setup (MVM) that uses Docker. It gives more control than the classic setup, but is in beta and still pretty bug-ridden. That only allows usage of "google.golang.org/appengine/..."
• goapp is a custom compiled version of go that treats "appengine/..." as stdlib packages. It is still around, supported and exclusively used by many users.
• "google.golang.org/appengine/..." is as of now a mostly complete port of the original appengine packages, but is still lacking some features. As a standard go gettable package, it works with either go or goapp

It feels like the Google team is actively trying to have people migrate away from using "appengine/..." that only works with goapp, but it also appears like they are very serious about BC and haven't announced any deprecation plans.