search

trezor / trezord-go

:smiling_imp: Trezor Communication Daemon (written in Go)
GNU Lesser General Public License v3.0
244 stars 146 forks source link

Unable to build on go =< 1.8 #80

Closed xaionaro closed 6 years ago

xaionaro commented 6 years ago

Some applications (for example gocryptfs) supports building on go 1.5-1.10. But trezord-go supports building only on 1.9-1.10. Otherwise:

.../usb/bus.go:14: syntax error: unexpected = in type declaration
.../usb/bus.go:15: syntax error: unexpected = in type declaration
.../usb/bus.go:16: syntax error: unexpected = in type declaration

In the meantime usbhid was moved into trezord-go while it (usbhid) was used by conejoninja/tesoro (used by xaionaro-go/cryptoWallet used by rfjakob/gocryptfs). So it (gocryptfs, cryptoWallet and tesoro) cannot pass a check of go vet on go 1.5-1.8, now.

Can you remove this aliases from usb/bus.go? IMO, it's too early for this feature to be used.

xaionaro commented 6 years ago

I'll try to prepare a Pull Request with fixes of all problems for go1.5-1.8

karelbilek commented 6 years ago

Ha, I did not know anyone else uses usbhid, sorry for deleting it and causing a mess, but again as I wrote elsewhere, it stopped making sense outside of trezord-go.

Btw, if someone imports import "github.com/trezor/trezord-go/usb/lowlevel", it does not need to build whole trezord-go, no?

xaionaro commented 6 years ago

Ha, I did not know anyone else uses usbhid, sorry for deleting it and causing a mess,

It's OK :)

Btw, if someone imports import "github.com/trezor/trezord-go/usb/lowlevel", it does not need to build whole trezord-go, no?

Yes, but there're "vendored" packaged (that are in the vendor/ directory). And dependency repositories are cloned fully into there. So when you run go vet ./... (or any other linter) with vendored trezord-go, you get this (or other) error.

karelbilek commented 6 years ago

Oooh, linters control all vendored packages, even when they are not used directly. Makes sense!

karelbilek commented 6 years ago

Hm, we are using sort.Slice and that seems to be introduced in 1.8, and I don't want to add another dependency just for that...

I think requesting >=1.8 is reasonable?

karelbilek commented 6 years ago

Hm, we can sort by sort#Interface, but I am not sure the readability loss is worth the compatibility reasons...

karelbilek commented 6 years ago

I have added tests for >= 1.8 to travis, it seems to work fine. I will add that to readme too.

xaionaro commented 6 years ago

I'm preparing a PR. It will be ready soon :)

ATM, I've fixed building for >=go1.6.

xaionaro commented 6 years ago

Thank you. The problem is closed.

karelbilek commented 6 years ago

I will write here for example, so you see the message

The 1.5 go build now started to break

https://travis-ci.org/trezor/trezord-go/jobs/425663224

It's probably something to do with some go modules? I have no idea.

karelbilek commented 6 years ago

We put away the go 1.5 build.

karelbilek commented 5 years ago

Hey. I am now trying to rewrite trezord-go so it is more dev-friendly as a library, but ... I am not sure if the <=1.8 capability is really necessary.

Type aliasing is really useful... maybe all people already upgraded to 1.9? It's from august 2017...

karelbilek commented 5 years ago

Hm, I might refactor the code more so they are not needed in the end