Problems with cache

[Peter Kleiweg]

Since Go 1.10, the cache causes many headaches. You can disable the cache with GOCACHE=off. Unless you work on mega projects, you don't need a cache anyway. But disabling the cache won't be an option in Go 1.12. What to do then? Stick with old version of Go?

The release notes for Go 1.11 have this to say:

" Go 1.11 will be the last release to support setting the environment variable GOCACHE=off to disable the build cache, introduced in Go 1.10. Starting in Go 1.12, the build cache will be required, as a step toward eliminating $GOPATH/pkg. The module and package loading support described above already require that the build cache be enabled. If you have disabled the build cache to avoid problems you encountered, please file an issue to let us know about them. "

However, when you file an issue, they tell you "it is working as intended". 

[Jakob Borg]

On 25 Aug 2018, at 15:21, Peter Kleiweg <pkle...@xs4all.nl> wrote:

disabling the cache won't be an option in Go 1.12. What to do then?

You don’t say what your issues with the build cache are. If you did, you might get suggestions.

//jb

[Peter Kleiweg]

Op zaterdag 25 augustus 2018 16:40:55 UTC+2 schreef Jakob Borg:

On 25 Aug 2018, at 15:21, Peter Kleiweg <pkle...@xs4all.nl> wrote:

disabling the cache won't be an option in Go 1.12. What to do then?

You don’t say what your issues with the build cache are. If you did, you might get suggestions.

Actually, setting GOCACHE=off doesn't solve all problems. So I am now back to Go version 1.9.7

Some problems:

 - You can't use packages that require local adjustments to the environment to install.

 - Code completion in Emacs doesn't work (using gocode)

 - Running Go in a Jupyter Notebook (using lgo) is slow with Go version 1.10 and higher.

 

[Ian Lance Taylor]

On Sat, Aug 25, 2018 at 7:58 AM, Peter Kleiweg <pkle...@xs4all.nl> wrote:
> Op zaterdag 25 augustus 2018 16:40:55 UTC+2 schreef Jakob Borg:
>>
>> On 25 Aug 2018, at 15:21, Peter Kleiweg <pkle...@xs4all.nl> wrote:
>>
>>
>> disabling the cache won't be an option in Go 1.12. What to do then?
>>
>>
>> You don’t say what your issues with the build cache are. If you did, you
>> might get suggestions.
>
>
> Actually, setting GOCACHE=off doesn't solve all problems. So I am now back
> to Go version 1.9.7
>
> Some problems:
>
> - You can't use packages that require local adjustments to the environment
> to install.

Can you expand on this. I'm not sure what you mean.

> - Code completion in Emacs doesn't work (using gocode)

That sounds like a bug to be fixed. The golang.org/x/go/packages
package is intended to use the build cache for input where
appropriate. The likely path forward will be to make gocode use
go/packages.

> - Running Go in a Jupyter Notebook (using lgo) is slow with Go version 1.10
> and higher.

I don't know what lgo is. In general the cache does not slow down the
build. Quite the opposite: in my experience, it speeds it up. If you
see cases where the cache makes things slower, please report them so
that they can be fixed.

Ian

[Sebastien Binet]

On Sat, Aug 25, 2018 at 6:54 PM Ian Lance Taylor <ia...@golang.org> wrote:

On Sat, Aug 25, 2018 at 7:58 AM, Peter Kleiweg <pkle...@xs4all.nl> wrote:
> Op zaterdag 25 augustus 2018 16:40:55 UTC+2 schreef Jakob Borg:
>>
>> On 25 Aug 2018, at 15:21, Peter Kleiweg <pkle...@xs4all.nl> wrote:
>>
>>
>> disabling the cache won't be an option in Go 1.12. What to do then?
>>
>>
>> You don’t say what your issues with the build cache are. If you did, you
>> might get suggestions.
>
>
> Actually, setting GOCACHE=off doesn't solve all problems. So I am now back
> to Go version 1.9.7
>
> Some problems:
>
>  - You can't use packages that require local adjustments to the environment
> to install.

Can you expand on this.  I'm not sure what you mean.


>  - Code completion in Emacs doesn't work (using gocode)

That sounds like a bug to be fixed.  The golang.org/x/go/packages
package is intended to use the build cache for input where
appropriate.  The likely path forward will be to make gocode use
go/packages.

in my experience, nsf/gocode was quite problematic to properly handle Go version bumps (I would end-up with "PANIC" messages in vim-go, resulting from a weird mix of a new Go compiler, gocode using parts of the old one, and my local code that would use the new one.)

I migrated to mdempsky/gocode. never looked back.

>  - Running Go in a Jupyter Notebook (using lgo) is slow with Go version 1.10
> and higher.

I don't know what lgo is.  In general the cache does not slow down the
build.  Quite the opposite: in my experience, it speeds it up.  If you
see cases where the cache makes things slower, please report them so
that they can be fixed.

Ian: that's https://github.com/yunabe/lgo

Peter: you could try the one from gopherdata:  https://github.com/gopherdata/gophernotes

-s

[Peter Kleiweg]

Op zaterdag 25 augustus 2018 18:54:32 UTC+2 schreef Ian Lance Taylor:

On Sat, Aug 25, 2018 at 7:58 AM, Peter Kleiweg <pkle...@xs4all.nl> wrote:
> Op zaterdag 25 augustus 2018 16:40:55 UTC+2 schreef Jakob Borg:
>>
>> On 25 Aug 2018, at 15:21, Peter Kleiweg <pkle...@xs4all.nl> wrote:
>>
>>
>> disabling the cache won't be an option in Go 1.12. What to do then?
>>
>>
>> You don’t say what your issues with the build cache are. If you did, you
>> might get suggestions.
>
>
> Actually, setting GOCACHE=off doesn't solve all problems. So I am now back
> to Go version 1.9.7
>
> Some problems:
>
>  - You can't use packages that require local adjustments to the environment
> to install.

Can you expand on this.  I'm not sure what you mean.

See this issue: https://github.com/golang/go/issues/27027

 

>  - Code completion in Emacs doesn't work (using gocode)

That sounds like a bug to be fixed.  The golang.org/x/go/packages
package is intended to use the build cache for input where
appropriate.  The likely path forward will be to make gocode use
go/packages.


>  - Running Go in a Jupyter Notebook (using lgo) is slow with Go version 1.10
> and higher.

I don't know what lgo is.  In general the cache does not slow down the
build.  Quite the opposite: in my experience, it speeds it up.  If you
see cases where the cache makes things slower, please report them so
that they can be fixed.

It says here: https://github.com/yunabe/lgo#go110

" lgo works with go1.10. But the overhead of code execution is 4-5x larger in go1.10 than go1.9. It is due to a regression of the cache mechnism of go install in go1.10. I recommend you to use lgo with go1.9 until the bug is fixed in go1.10. "

[Peter Kleiweg]

Op zaterdag 25 augustus 2018 19:06:27 UTC+2 schreef Sebastien Binet:

On Sat, Aug 25, 2018 at 6:54 PM Ian Lance Taylor <ia...@golang.org> wrote:

On Sat, Aug 25, 2018 at 7:58 AM, Peter Kleiweg <pkle...@xs4all.nl> wrote:
> Op zaterdag 25 augustus 2018 16:40:55 UTC+2 schreef Jakob Borg:
>>
>> On 25 Aug 2018, at 15:21, Peter Kleiweg <pkle...@xs4all.nl> wrote:
>>
>>
>> disabling the cache won't be an option in Go 1.12. What to do then?
>>
>>
>> You don’t say what your issues with the build cache are. If you did, you
>> might get suggestions.
>
>
> Actually, setting GOCACHE=off doesn't solve all problems. So I am now back
> to Go version 1.9.7
>
> Some problems:
>
>  - You can't use packages that require local adjustments to the environment
> to install.

Can you expand on this.  I'm not sure what you mean.


>  - Code completion in Emacs doesn't work (using gocode)

That sounds like a bug to be fixed.  The golang.org/x/go/packages
package is intended to use the build cache for input where
appropriate.  The likely path forward will be to make gocode use
go/packages.

in my experience, nsf/gocode was quite problematic to properly handle Go version bumps (I would end-up with "PANIC" messages in vim-go, resulting from a weird mix of a new Go compiler, gocode using parts of the old one, and my local code that would use the new one.)

I migrated to mdempsky/gocode. never looked back.

I tried this. It works for me too.

 

>  - Running Go in a Jupyter Notebook (using lgo) is slow with Go version 1.10
> and higher.

I don't know what lgo is.  In general the cache does not slow down the
build.  Quite the opposite: in my experience, it speeds it up.  If you
see cases where the cache makes things slower, please report them so
that they can be fixed.

Ian: that's https://github.com/yunabe/lgo

Peter: you could try the one from gopherdata:  https://github.com/gopherdata/gophernotes

Yes,  it works, but is it as good as lgo? I don't know if this comparison is up to date:

https://github.com/yunabe/lgo#gophernotes

[Ian Lance Taylor]

On Sat, Aug 25, 2018 at 5:16 PM, Peter Kleiweg <pkle...@xs4all.nl> wrote:
> Op zaterdag 25 augustus 2018 18:54:32 UTC+2 schreef Ian Lance Taylor:
>>
>> On Sat, Aug 25, 2018 at 7:58 AM, Peter Kleiweg <pkle...@xs4all.nl> wrote:
>> > Op zaterdag 25 augustus 2018 16:40:55 UTC+2 schreef Jakob Borg:
>> >>
>> >> On 25 Aug 2018, at 15:21, Peter Kleiweg <pkle...@xs4all.nl> wrote:
>> >>
>> >>
>> >> disabling the cache won't be an option in Go 1.12. What to do then?
>> >>
>> >>
>> >> You don’t say what your issues with the build cache are. If you did,
>> >> you
>> >> might get suggestions.
>> >
>> >
>> > Actually, setting GOCACHE=off doesn't solve all problems. So I am now
>> > back
>> > to Go version 1.9.7
>> >
>> > Some problems:
>> >
>> > - You can't use packages that require local adjustments to the
>> > environment
>> > to install.
>>
>> Can you expand on this. I'm not sure what you mean.
>>
>
> See this issue: https://github.com/golang/go/issues/27027

Thanks, but disabling the cache won't fix that issue. The issue there
is that the go tool has gotten more precise about when packages are up
to date, and will try to rebuild them if they are not up to date.
There is already a way to handle this: //go:binary-only-package.

Ian