go: cmd/go: malformed file path: invalid char ':'

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.11.1 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

GOARCH=“amd64” GOBIN=“” GOCACHE=“/Users/vit/Library/Caches/go-build” GOEXE=“” GOFLAGS=“” GOHOSTARCH=“amd64” GOHOSTOS=“darwin” GOOS=“darwin” GOPATH=“/Users/vit/go-code” GOPROXY=“” GORACE=“” GOROOT=“/usr/local/Cellar/go/1.11.1/libexec” GOTMPDIR=“” GOTOOLDIR=“/usr/local/Cellar/go/1.11.1/libexec/pkg/tool/darwin_amd64” GCCGO=“gccgo” CC=“clang” CXX=“clang++” CGO_ENABLED=“1” GOMOD=“/Users/vit/go-code/devexp/go.mod” CGO_CFLAGS=“-g -O2” CGO_CPPFLAGS=“” CGO_CXXFLAGS=“-g -O2” CGO_FFLAGS=“-g -O2” CGO_LDFLAGS=“-g -O2” PKG_CONFIG=“pkg-config” GOGCCFLAGS=“-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/6_/htkppg753px1jglygs0c297h0000gn/T/go-build852474991=/tmp/go-build -gno-record-gcc-switches -fno-common”

What did you do?

Try consuming a repo which has non-go files that contain “:” in their filenames.

What did you expect to see?

Repo can be imported as a dependency.

What did you see instead?

Error that says: malformed file path … invalid char ‘:’

Notes:

This issue should be similar to the https://github.com/golang/go/issues/27642

Would it be possible to relax some of these naming restrictions? Having to work with third-party package owners for each dependency that might contain these special symbols in filenames sounds like a lot of pain.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 3
  • Comments: 20 (12 by maintainers)

Commits related to this issue

Most upvoted comments

You must be thinking in terms of centralized codebase where such things can be done easier. I don’t think we can guarantee on the go toolchain level that tests would succeed on all platforms or that package would even build, if package is not supporting some platforms due to whatever reasons be that file naming, build constraints or platform dependent code, it should be totally fine. For example if I want to write a package that only works on Linux and you find it useful, you should be able to consume it if you are going to use it only on Linux.

On the other hand I’m not going to justify usefulness of those filenames and if you think that community will figure this out and will clean up code over time then I’m okay with it.

On Thu, Oct 4, 2018 at 2:11 PM Bryan C. Mills notifications@github.com wrote:

If they are non-Go files needed for testing some Go package, then go test all will erroneously report test failures if the package is used.

If they are non-Go files that are also not needed for testing any Go package, why can’t they be pruned out of the Go module in the first place (e.g. by adding another go.mod)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/28001#issuecomment-427170102, or mute the thread https://github.com/notifications/unsubscribe-auth/ABQDzvS765wSCGIjlGhOb0t_VgB9nwPHks5uhnlwgaJpZM4XHL3B .