Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: document that filesystem-based replace directives require that the right hand side have a go.mod #30847
What version of Go are you using (
changed the title
Document that filesystem-based replace directives do require that the right hand side have a go.mod
Mar 14, 2019
This is likely related to #24110
@rsc states that this is "working as intended", but it doesn't seem obvious to me why the stated rationale applies - after all, go modules interop with non-go module adopting libraries fine outside of replace directives.
In fact without the replace directive, if I want to use the public, non-forked version of said dependency, go modules seems to work with it fine...
A related comment from Bryan:
changed the title
Document that filesystem-based replace directives require that the right hand side have a go.mod
Mar 15, 2019
referenced this issue
Mar 28, 2019
FWIW, I think having a filesystem-based replace without a go.mod on the right-hand side is actually useful.
I was expecting to use that for the following case:
I have a large, curated existing GOPATH, made up of operating system packages for various Go libraries and to be used for builds of other OS packages (that's NetBSD pkgsrc, if you are wondering). Now I would like to replace a given module with its equivalent in the existing GOPATH.
Because we are early in the development of modules, most of these have no go.mod of their own. Running
Or am I thinking about this the wrong way?
So,.... I've been bitten by #26366 for CGO-using module X, which is really annoying. I had hoped I could then just define a project local GOPATH= and have my main package in /src/main-package and have /src/X ... but no. GOPATH also stops working when GO111MODULE=on.
All I wanted here was for go build -mod=vendor to find module X in it's complete form. Can it really be true that we have to introduce yet-another-tool to make this work. I had hoped to just use git and go.