FAQ
A couple of questions about Go on GAE: what is the timeline for moving the GAE Go runtime to 1.3? and is there any plan to change the behaviour of go-app-builder to more closely conform to the normal build system (and so allowing directory structures that currently return a file conflict)?

thanks
Dan

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • David Symonds at Aug 25, 2014 at 11:29 pm
    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.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Aug 25, 2014 at 11:37 pm
    Thanks.
    On Tue, 2014-08-26 at 09:29 +1000, David Symonds wrote:
    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.
    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

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • David Symonds at Aug 25, 2014 at 11:56 pm

    On 26 August 2014 09:37, Dan Kortschak wrote:

    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).
    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.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Aug 26, 2014 at 12:06 am

    On Tue, 2014-08-26 at 09:56 +1000, David Symonds wrote:
    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

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • David Skinner at Aug 26, 2014 at 12:04 am
    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!


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • David Symonds at Aug 26, 2014 at 12:32 am

    On 26 August 2014 10:04, David Skinner wrote:

    I hate to seem disagreeable but the go-app-builder does not conform to the
    normal build system.
    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.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • David Skinner at Aug 26, 2014 at 1:05 am
    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.
    On Monday, August 25, 2014 7:33:00 PM UTC-5, David Symonds wrote:

    On 26 August 2014 10:04, David Skinner <skinne...@gmail.com <javascript:>>
    wrote:
    I hate to seem disagreeable but the go-app-builder does not conform to the
    normal build system.
    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.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 25, '14 at 9:22p
activeAug 26, '14 at 1:05a
posts8
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase