mdempsky/unconvert

Failure with go-1.10.x, caused by a new `go list` argument `-compiled`

drmingdrmer opened this issue · 7 comments

drmingdrmer commented

To reproduce:

With a clean go-1.10.x(without any installed package. Such as in travis):

  • Install unconvert: 
    go get github.com/mdempsky/unconvert
  • Run it: unconvert math/bits, it reports an error: 
    2019/03/25 16:25:53 unsupported version of go: exit status 2: flag provided but not defined: -compiled
usage: list [-e] [-f format] [-json] [build flags] [packages]
Run 'go help list' for details.

Cause

  1. unconvert relies on golang.org/x/tools/go/packages.
  2. go get in a clean env pulls the latest golang.org/x/tools/go/packages.
  3. The latest golang.org/x/tools/go/packages(the master) is for latest go(1.12.x) and it assumes that go list is able to accept the argument -compiled.
  4. An older go(e.g. 1.10.x) does not support -compiled for go list. Thus install unconvert in a clean go-1.10.x env results in an error like above.

As go get can not specify dependency versions, using dep to force the revision of packages to use might solve this problem.

mdempsky commented

Thanks for the report. Out of curiosity, what motivates your interest in supporting Go 1.10?

The Go project only supports the latest two releases, which is now 1.12 and 1.11. If they're not supporting 1.10, I'm not inclined to support 1.10 either. But I'm open to hearing alternative viewpoints.

  • 👍1
drmingdrmer commented

Because my current project is based on Go-1.10. That's the only reason. 😭

According to your point that go only supports two release, it is not necessary to bother you:).

mdempsky commented

Because my current project is based on Go-1.10.

I see. I think it should be possible for you to build unconvert using Go 1.12 and then run it against your Go-1.10-based project's source code? Is that not working for you?

  • 👍1
drmingdrmer commented

Because my current project is based on Go-1.10.

I see. I think it should be possible for you to build unconvert using Go 1.12 and then run it against your Go-1.10-based project's source code? Is that not working for you?

Yes, locally I can do this.

Actually, the problem is with travis. In travis it starts a clean environment with only a go-1.10 . Thus all of the checking tools need to be downloaded and compiled in this travis environment.
That's why I need unconvert to be able to be compiled with go-1.10 . :(

dmitshur commented

An approach is to compile unconvert ahead of time (using Go 1.12), place the binary somewhere accessible over the internet, and set up Travis to download the binary instead of downloading its source and building it.

drmingdrmer commented

An approach is to compile unconvert ahead of time (using Go 1.12), place the binary somewhere accessible over the internet, and set up Travis to download the binary instead of downloading its source and building it.

Actually I've set up several CI env for Linux, Windows and also my local MacBook.
And the checking tasks are defined in a Makefile.
Thus maintaining 3 compiled version of unconvert and detecting OS in Makefile and then downloading the correct version of unconvert seems like an annoying work.

To my need, it is much easier to have a fork of unconvert which contains dependency itself, before I upgrade my project to go-1.12 . 😃

  • 👍1
mdempsky commented

Yeah, in that case maintaining a Go 1.10-compatible fork until you're able to move to Go 1.12 probably sounds like the best solution. Thanks for your understanding.

  • 👍1
  • ❤️1