[go-nuts] appengine runtime version and GOPATH conflicts

No timeline on Go 1.3 yet. A beta version will be announced on
google-appengine-go as usual, though.

go-app-builder already confirms to the normal build system, with the
proviso that there is a logical GOPATH to wherever the app.yaml is
(i.e. the app root). The conflict you are referencing is when a file
appears under two different import paths, usually as a result of that
logical GOPATH overlapping an existing GOPATH. It leads to confusing
enough behaviour that we made it an error; it's easy enough to solve
by moving the app.yaml and a skeleton bootstrap .go file into their
own directory.

Thanks.
Yeah, I understand the proximal reasons and the workaround. Can you
explain the need for a logical GOPATH for go-app-builder as opposed to
just using the existing GOPATH (I guess that was the basis for my
original question).

Dan

It's largely historical baggage, since a lot of this predates GOPATH
as a concept. We needed to define what the import path for a package
was in the app directory, and the full directory name relative to
app.yaml was chosen. One could argue that we could consider culling
that, and demanding that everyone use GOPATH, but there's a huge
number of apps that depend on this legacy behaviour so realistically
it's not going to change.

OK. No worries. Unfortunate, but not burdensome.

Dan

I have to say that I have grown accustomed to

  import "gopkg.in/whatever.v1"

and it seems that if the program is being compiled remotely, it should do
the go get remotely as well.

Yes, I can do a
git clone git@github.com:somebody/package.git
to a manually created directory with the desired path name and then try to
remember to update it maybe sometimes. It's just that I really like
go get -u
when I want to make sure everything is up to date and I don't mind if
something breaks.

I hate to seem disagreeable but the go-app-builder does not conform to the
normal build system.

By the way, I really love Go on app-engine! Great job!

The normal go tool does not automatically do a `go get` either, so the
Go App Engine tools *are* consistent with the normal build system in
that way.

I stand corrected.

Perhaps I should say that while the go-app-builder meets specifications, it
did not meet this users expectations.

I suppose that my expectations for a remote build process based on a
different tool chain simply was not the same as yours. I would have thought
that you would have needed to fetch the source code most appropriate for
the version of go being used by your go-app-builder and not the version
that I happen be using in local development. But that is just me and my
expectations. I have experienced no bugs or problems so far, so I am happy.