Please sign in to comment.
TL;DR: A project with: - a valid semver tag equal or above v3.0.0 - with a go.mod file - but not using versioned imports is not supported by Go in modules mode; GO111MODULE=on on previous version, and anything but GO111MODULE=off on likely 1.13 or newer when the default is switched. The only way to keep it working simultaneously on versions below 1.9.7 and above 1.11 in go module mode is to remove the go.mod file. It is currently expected that v4.0.0 will be released with a go.mod file, which will break Go toolchains before 1.9.7. As a note, the minimum tested version is currently 1.7.6. Even then, there's some fun. This is because of the source files using '// +build periphextra'. The tag 'periphextra' only has effect when building executables under cmd/ and experimental/cmd/. When set, these executables call hostextra.Init() from periph.io/x/extra/hostextra instead of host.Init() from periph.io/x/periph/host. The reason is that periph.io/x/extra contains all drivers that have external dependencies, while periph.io/x/periph itself aims to not have any external dependencies. Yet, it's useful to be able to use, let's say, a FT232H with cmd/gpio-read. Hence the optional build tag. The problem is that then go mod complains, because it sees the periph.io/x/extra/hostextra import, and wants to add it as a dependency in go.sum. Hello circular dependency! I'm not yet sure how I'll handle this beside hacking manually the go.sum file or removing this option at all.
- Loading branch information...