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)
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: