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.
The central issue is lack of documentation. Concrete steps are described
well, but the underlying principles aren't discussed, e.g. "you can use the
gcloud tool or goapp" but it's unstated why you would prefer one over the
other. The implicit assumption that both may be used in parallel is never
mentioned. The documentation also doesn't leave me in a position to make an
informed decision about how to proceed, or even which underlying issues
affect my choice (Go 1.6 support...)
This may be a quirk for me, but I'm very concerned about writing
"appengine" code vs. writing Go. Appengine should ideally be one possible
deployment plattform. The fact that I have to provide facilities to isolate
the custom http client and have to find a way to deal with having to drag
around a custom context already irks me. Necessitating custom build-tooling
makes the plattform seem even more intrusive. In an ideal world, I would
have been able to just use a stock `go` binary (like the java people can
just continue to use maven or gradle).
To me the issues boiled down to the fact that vanilla 1.6 SDK support is
not trivial to install in parallel to a current SDK (lack of support for
older versions extends down to the documentation level: no older SDK docs
are online and it's hard to figure out which features are not availables as
there's no indication of new/deprecated methods, anlagog to javadocs @since
and @deprecated. E.g. I spent a considerable amount of time trying to
figure out why using xml.Encoder's Indent() broke the build ... )
`goapp` to me seems like a good comprise as it just wraps the standard `go`
commands for day-to-day development use. I don't want to learn anything new
to use appengine, or at least not more than a bullet list of
considerations. `goapp` also conventiently includes 1.6 everything; I
don't have to change or uninstall anything or create an isolated vm.
The following would be helpful additions to the documentation (for me):
- provide a bit of general abstract background about appengine and it's
restrictions and how go fits in / go's limitations
- even if there are numerous possible workflows, provide at least one
concrete example of the 'intended' workflow, including installing a
parallel 1.6 go (or using the one provided by the SDK), how to set up the
environment of $GO... variables, how to install libs, how to run unit tests
... This would work well with the opinionated nature of Go in general, i.e.
there is an intended and correct way of doing things and it's explicit
(gofmt).
- provide Godoc for the entire appengine api including the 1.6 SDK (and in
the standard godoc format!)
Ideally, open the discussions of the go appengine development team to the
outside world, in the same manner that most of the core go development
takes place in the open. You guys have obviously put a lot of though into
these issues already, and having these discussions out in the open would
help understand the implicit assumptions without having to officially
document them.
Thanks!
-tim
--
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/bde19fab-68e7-4122-9693-149068f5489a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
