Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: file system replace only works if target has go.mod #31052

Closed
bsiegert opened this issue Mar 26, 2019 · 4 comments

Comments

Projects
None yet
3 participants
@bsiegert
Copy link
Contributor

commented Mar 26, 2019

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

$ go version
go version go1.12.1 linux/amd64

Does this issue reproduce with the latest release?

Yes.

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

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/bsiegert/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/bsiegert/go"
GOPROXY=""
GORACE=""
GOROOT="/home/bsiegert/pkg/go112"
GOTMPDIR=""
GOTOOLDIR="/home/bsiegert/pkg/go112/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/bsiegert/src/github.com/bsiegert/lf/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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build475195531=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I have some code that depends on github.com/mattn/go-runewidth, which has semver tags but no go.mod file.

The replace directive in go.mod allows replacing a dependent module with local code by giving it a path. So I tried the following to use my local copy of the go-runewidth package (inside an existing GOPATH, by the way):

module github.com/bsiegert/lf

go 1.12

require (
        github.com/mattn/go-runewidth v0.0.3
        github.com/nsf/termbox-go v0.0.0-20180613055208-5c94acc5e6eb
)

replace github.com/mattn/go-runewidth => /home/bsiegert/pkg/gopkg/src/github.com/mattn/go-runewidth

What did you expect to see?

I expected go build to use that copy of the package, whether it has a go.mod file or not.

What did you see instead?

$ go build
go: parsing ../../../../pkg/gopkg/src/github.com/mattn/go-runewidth/go.mod: open /home/bsiegert/pkg/gopkg/src/github.com/mattn/go-runewidth/go.mod: no such file or directory
go: error loading module requirements

Adding a go.mod file with just the "module" line in the go-runewidth directory makes the build work.

I thought that was surprising, and it reduces the value proposition of replace while many dependencies do not have go.mod files yet.

@jayconrod

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

I suspect there is a good reason for this, but it would be good if @bcmills can confirm.

File system replacements are very commonly in a subdirectory of a module. The presence of a go.mod file in the replacement directory makes it clear that everything in that directory is not part of the containing module.

@bcmills

This comment has been minimized.

Copy link
Member

commented Mar 28, 2019

In general there are two kinds of replacements: replacing the source code for a module with a modified version of that source code with the same import path, and replacing one module with an entirely different module. (The latter mode is buggy at the moment, but it ought to work and it will work better in the near future.)

We can distinguish between those two modes using the module path declared in the go.mod file, which tells us the import path prefix for all of the packages contained within that module: if the path exactly matches the path of the module to be replaced, then we have a source-code replacement; otherwise, we have a one-module-with-another replacement and need to reinterpret the import paths accordingly.

If there is no go.mod file in the replacement directory, then we cannot distinguish between those two modes: we don't know which import paths refer to packages in the same module and which refer to packages in external modules.

@bcmills

This comment has been minimized.

Copy link
Member

commented Mar 28, 2019

We could perhaps interpret a replacement path without a go.mod file as always being the source-code style replacement, but given that it is easy to run go mod init $MODULENAME in the local filesystem, having an explicit module path seems more robust.

@bcmills bcmills added this to the Unplanned milestone Mar 28, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Mar 28, 2019

Duplicate of #30847

@bcmills bcmills closed this Mar 28, 2019

@bcmills bcmills marked this as a duplicate of #30847 Apr 13, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.