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

[vitarb]

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 #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.

[mvdan]

Somewhat related to #26912, but that was about a replace directive and this is a bout a filename.

/cc @bcmills

[myitcv]

Sounds like (away from keyboard) a dup of #26672

[mvdan]

You're right. But perhaps the workaround there isn't satisfactory here - let's see what @vitarb has to say.

[bcmills]

Would it be possible to relax some of these naming restrictions?

Modules are intended to be portable across platforms, and the : character is reserved on Windows.

[DeedleFake]

He's saying that it's non-Go files in the repo that are causing it, though, not the module path itself, or even files that the toolchain is going to care about directly. It looks like Git for Windows just ignores the files, which means that they'll wind up deleted if you commit and you're not paying attention. Since these are apparently files that aren't an issue in terms of importing the repository and the module is presumably being cloned into the cache where commits are fairly unlikely to happen, maybe the tools could complain only if it's a Go, C, or assembly file that's illegal?

[bcmills]

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

[vitarb]

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 ***@***.***> 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 <#28001 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQDzvS765wSCGIjlGhOb0t_VgB9nwPHks5uhnlwgaJpZM4XHL3B> .

[bcmills]

if you think that community will figure this out and will clean up code over time then I'm okay with it.

We've only had a few related reports so far, so it doesn't seem to be a major pain point yet (and should only improve over time). Let's keep the validation as-is, and we can revisit if we find that there are a lot more repos that can't be converted to modules.