search

maxsupermanhd / FactoCord-3.0

Factorio bidirectional Discord bridge bot for Linux servers with control functionality.
Apache License 2.0
14 stars 10 forks source link

[BUG] Cannot build: "local import in non-local package" #35

Closed jlucktay closed 4 years ago

jlucktay commented 4 years ago

BUG-FILTER-CHECKLIST. Anyone who opens up a bug report must fill these checkboxes (add an "x" to [ ] to be like [x]) to assume that he acknowledged that he red README.md and followed checklist below.

Describe the bug Cannot build FactoCord-3.0 with current version of Go (1.14), both without and with a go.mod file.

To Reproduce

$ go version
go version go1.14.4 darwin/amd64

$ go build ./...
go: cannot find main module, but found .git/config in /home/jameslucktaylor/git/github.com/maxsupermanhd/FactoCord-3.0
        to create a module there, run:
        go mod init

$ go mod init github.com/maxsupermanhd/FactoCord-3.0
go: creating new go.mod: module github.com/maxsupermanhd/FactoCord-3.0

$ go build ./...
main.go:12:2: local import "./commands/admin" in non-local package
main.go:13:2: local import "./discord" in non-local package
main.go:14:2: local import "./support" in non-local package
commands/commands.go:7:2: local import "./admin" in non-local package
commands/commands.go:8:2: local import "./utils" in non-local package
commands/commands.go:6:2: local import "../support" in non-local package
commands/admin/ban.go:6:2: local import "../../support" in non-local package
commands/utils/mods.go:8:2: local import "../../support" in non-local package
discord/chat.go:11:2: local import "../commands" in non-local package
discord/cache.go:8:2: local import "../support" in non-local package

Expected behavior Expect go build to produce a working binary, and go build ./... to exit with a status of zero and without any errors.

My instance information

Screenshots

maxsupermanhd commented 4 years ago

Hi, why are you using go build ./..., ./... to be exact? It should work from-the-box with just clone and go build. Builds on WSL1 (TechoStrife), Linux 4.15 (my own server) and GitHub Actions thingy without a problem. Is this MacOS specific?

TechnoStrife commented 4 years ago

@jlucktay ^

jlucktay commented 4 years ago

@maxsupermanhd go build ./... will make sure all packages can build cleanly. go build will produce a binary. When I tried, both of them were failing, as I wrote in the expected behaviour. I had the same issue on fresh GCE VMs running FreeBSD and Ubuntu, so it's not macOS-specific.

maxsupermanhd commented 4 years ago

That's very strange. If you are planning to use it as a "consumer" and will not do any code-related stuff you can just grab a release binary. Not really sure why you need "clean build" but I want to see logs of just git clone, go get ... and go build. (I mean logs from fresh VM with Ubuntu as you said)

TechnoStrife commented 4 years ago

I can't find any references to "clean build". To me both commands work on both master and your pull request, but go build ./... runs longer. However I did find that these errors might occur when building inside GOPATH directory

jlucktay commented 4 years ago

When I say "build cleanly" I mean, it can build without any errors or warnings from the compiler, and an exit status of 0.

I narrowed this issue down to newer versions of Go and the GO111MODULE env var. If you set it to on this will reproduce as I wrote.

More to the point, using relative paths as package imports aren't going to work with modules under more current releases of Go, so consider it future-proofing if nothing else.

The release notes for recent versions (1.12, 1.13, 1.14) and the docs on golang.org have more details about module behaviour and layout.

maxsupermanhd commented 4 years ago

That makes sense because it was originally coded for go 1.8