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

Jump to bottom

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

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

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

bsiegert opened this issue Mar 26, 2019 · 4 comments
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@bsiegert
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

bcmills 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
Copy link
Contributor

bcmills 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 the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 28, 2019
@bcmills bcmills added this to the Unplanned milestone Mar 28, 2019
@bcmills
Copy link
Contributor

bcmills commented Mar 28, 2019 •
edited

Duplicate of #30847

@bcmills bcmills closed this as completed Mar 28, 2019
@bcmills bcmills marked this as a duplicate of #30847 Apr 13, 2019
@golang golang locked and limited conversation to collaborators Apr 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
4 participants
@jayconrod @bsiegert @bcmills @gopherbot