cmd/go: fmt does not respect or have defined -mod #27841

emikalendra · 2018-09-25T05:52:49Z

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

go version go1.11 darwin/amd64

Does this issue reproduce with the latest release?

Yes. 1.11 is the current latest release

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

darwin/amd64

What did you do?

$ mkdir -p /tmp/scratch/fmtex
$ cd /tmp/scratch/fmtex
$ go mod init fmtex
$ cat <<EOF > hello.go
package main

import (
  "go.uber.org/zap"
)

func main() {
    logger, _ := zap.NewProduction()
    defer logger.Sync()
    logger.Info("Hello")
}
EOF

$ go run hello.go
$ go mod vendor
$ chmod -R 776 $GOPATH/pkg/mod/*
$ rm -rf $GOPATH/pkg/mod
$ export GOPROXY="off"
$ export GOFLAGS="-mod=vendor"
$ go run hello.go
{"level":"info","ts":1537854151.3013902,"caller":"fmtex/hello.go:10","msg":"Hello"}

This demonstrates that we have an example program using the vendor directory and GOPROXY is set to off.

Now we want to run go fmt

$ go fmt .
go: go.uber.org/atomic@v1.3.2: module lookup disabled by GOPROXY=off
go: go.uber.org/multierr@v1.1.0: module lookup disabled by GOPROXY=off
go: go.uber.org/zap@v1.9.1: module lookup disabled by GOPROXY=off
go: error loading module requirements

try using -mod=vendor

$ go fmt -mod=vendor .
flag provided but not defined: -mod
usage: go fmt [-n] [-x] [packages]
Run 'go help fmt' for details.

try using gofmt

$ gofmt -l .
hello.go

What did you expect to see?

go fmt should format source files using gofmt -l -w . . The documentation indicates:

Fmt runs the command 'gofmt -l -w' on the packages named
by the import paths. It prints the names of the files that are modified.

What did you see instead?

Instead of go fmt running gofmt -l -w . it first tries to load modules ignoring -mod=vendor. It is also unclear why go fmt requires loading modules if it just runs gofmt which works without loading modules.

The text was updated successfully, but these errors were encountered:

agnivade · 2018-09-25T06:54:35Z

/cc @bcmills @myitcv

myitcv · 2018-09-25T10:14:48Z

I think you have some sort of environment issue here. The following works for me:

export GOPATH=$(mktemp -d)
unset GOPROXY GOFLAGS
cd $(mktemp -d)
go mod init example.com/fmtex
cat <<EOF > hello.go
package main

import (
  "go.uber.org/zap"
)

func main() {
    logger, _ := zap.NewProduction()
    defer logger.Sync()
    logger.Info("Hello")
}
EOF

go run hello.go
go mod vendor
GOPROXY="off" GOFLAGS="-mod=vendor" go run hello.go
GOPROXY="off" GOFLAGS="-mod=vendor" go fmt .
GOPROXY="off" GOFLAGS="-mod=vendor" gofmt .

gives the output:

$ egrunner -out std script.sh
$ export GOPATH=/tmp/tmp.6JmYsgOqIM
$ unset GOPROXY GOFLAGS
$ cd /tmp/tmp.oZGjJxN1NV
$ go mod init example.com/fmtex
go: creating new go.mod: module example.com/fmtex
$ cat <<EOF >hello.go
package main

import (
  "go.uber.org/zap"
)

func main() {
    logger, _ := zap.NewProduction()
    defer logger.Sync()
    logger.Info("Hello")
}
EOF
$ go run hello.go
go: finding go.uber.org/zap v1.9.1
go: downloading go.uber.org/zap v1.9.1
go: finding go.uber.org/multierr v1.1.0
go: finding go.uber.org/atomic v1.3.2
go: downloading go.uber.org/multierr v1.1.0
go: downloading go.uber.org/atomic v1.3.2
{"level":"info","ts":1537870453.3103888,"caller":"tmp.vm8Xl8pJwF/hello.go:10","msg":"Hello"}
$ go mod vendor
$ GOPROXY="off" GOFLAGS="-mod=vendor" go run hello.go
{"level":"info","ts":1537870454.1195014,"caller":"tmp.vm8Xl8pJwF/hello.go:10","msg":"Hello"}
$ GOPROXY="off" GOFLAGS="-mod=vendor" go fmt .
hello.go
$ GOPROXY="off" GOFLAGS="-mod=vendor" gofmt .
package main

import (
        "go.uber.org/zap"
)
...

emikalendra · 2018-09-25T14:48:51Z

@myitcv I think you missed the step to remove the cached modules. Without the step, the cache is being used, ignoring -mod=vendor.

Modifying your example to include changing to a new GOPATH. Using rm -rf in the original example was probably not a good idea.

export GOPATH=$(mktemp -d)
unset GOPROXY GOFLAGS
cd $(mktemp -d)
go mod init example.com/fmtex
cat <<EOF > hello.go
package main

import (
  "go.uber.org/zap"
)

func main() {
    logger, _ := zap.NewProduction()
    defer logger.Sync()
    logger.Info("Hello")
}
EOF

go run hello.go
go mod vendor
GOPROXY="off" GOFLAGS="-mod=vendor" go run hello.go
GOPROXY="off" GOFLAGS="-mod=vendor" go fmt .
GOPROXY="off" GOFLAGS="-mod=vendor" gofmt -l .

export GOPATH=$(mktemp -d)
GOPROXY="off" GOFLAGS="-mod=vendor" go run hello.go
GOPROXY="off" GOFLAGS="-mod=vendor" go fmt .
GOPROXY="off" GOFLAGS="-mod=vendor" gofmt -l .

Gives output:

$ export GOPATH=$(mktemp -d)
$ unset GOPROXY GOFLAGS
$ cd $(mktemp -d)
$ go mod init example.com/fmtex
go: creating new go.mod: module example.com/fmtex
$ cat <<EOF > hello.go
> package main
> 
> import (
>   "go.uber.org/zap"
> )
> 
> func main() {
>     logger, _ := zap.NewProduction()
>     defer logger.Sync()
>     logger.Info("Hello")
> }
> EOF
$ 
$ go run hello.go
go mod vendor
GOPROXY="off" GOFLAGS="-mod=vendor" go run hello.go
GOPROXY="off" GOFLAGS="-mod=vendor" go fmt .
GOPROXY="off" GOFLAGS="-mod=vendor" gofmt -l .

export GOPATH=$(mktemp -d)
GOPROXY="off" GOFLAGS="-mod=vendor" go run hello.go
GOPROXY="off" GOFLAGS="-mod=vendor" go fmt .
GOPROXY="off" GOFLAGS="-mod=vendor" gofmt -l .
go: finding go.uber.org/zap v1.9.1
go: downloading go.uber.org/zap v1.9.1
go: finding go.uber.org/multierr v1.1.0
go: finding go.uber.org/atomic v1.3.2
go: downloading go.uber.org/multierr v1.1.0
go: downloading go.uber.org/atomic v1.3.2
{"level":"info","ts":1537886400.8363662,"caller":"/hello.go:10","msg":"Hello"}
$ go mod vendor
$ GOPROXY="off" GOFLAGS="-mod=vendor" go run hello.go
{"level":"info","ts":1537886401.973213,"caller":"/hello.go:10","msg":"Hello"}
$ GOPROXY="off" GOFLAGS="-mod=vendor" go fmt .
hello.go
$ GOPROXY="off" GOFLAGS="-mod=vendor" gofmt -l .
 
$ export GOPATH=$(mktemp -d)

$ GOPROXY="off" GOFLAGS="-mod=vendor" go run hello.go
{"level":"info","ts":1537886402.843414,"caller":"/hello.go:10","msg":"Hello"}
$ GOPROXY="off" GOFLAGS="-mod=vendor" go fmt .
go: go.uber.org/zap@v1.9.1: module lookup disabled by GOPROXY=off
go: go.uber.org/atomic@v1.3.2: module lookup disabled by GOPROXY=off
go: go.uber.org/multierr@v1.1.0: module lookup disabled by GOPROXY=off
go: error loading module requirements
$ GOPROXY="off" GOFLAGS="-mod=vendor" gofmt -l .

myitcv · 2018-09-25T15:02:05Z

I think you missed the step to remove the cached modules.

I did indeed forget to ask why you had included that :)

Makes sense now, thanks.

cc @rsc @bcmills to confirm expected behaviour here. I suspect this is also an issue for the other tools (vet, fix etc?)

Using rm -rf in the original example was probably not a good idea.

You probably wanted go clean -modcache?

emikalendra · 2018-09-25T15:23:04Z

You probably wanted go clean -modcache?

Yes. Thank you. That would have made the example clearer.

rsc · 2018-10-25T16:52:22Z

Most commands take all the build flags (documented in go help build) but a few, including fmt, know that most of the build flags are irrelevant if you're only loading packages and not building them, and so they only accept -n and -x. But -mod is now also relevant to package loading and should be included in those commands. Probably anything using base.AddBuildFlagsNX should be checked to see if should be something like AddLoadFlags instead.

coolaj86 · 2019-03-25T20:42:26Z

I tried using the env form, but that did not work out as hoped...

export GOFLAGS="-mod=vendor"

//go:generate go fmt ./...

go generate ./...

Still downloaded loads of stuff instead of using the vendor directory.

Fixes golang#27841 Change-Id: Ifcfd938aff8680cf7b44dfc09fde01d6105345a0

gopherbot · 2019-10-01T17:06:43Z

Change https://golang.org/cl/198257 mentions this issue: cmd/go: respect -mod flag in fmt

`go fmt` doesn't seem to respect `-mod=vendor` golang/go#27841 Instead try using `gofmt` which doesn't trigger downloading dependencies in the first place. However, `gofmt` affects files under `vendor/`, so we reset that before checking for changes.

This removes network loads until `go fmt` stops trying to download those resources. golang/go#27841 has more information.

emikalendra changed the title ~~go fmt does respect or have defined -mod~~ go fmt does not respect or have defined -mod Sep 25, 2018

agnivade changed the title ~~go fmt does not respect or have defined -mod~~ cmd/go: fmt does not respect or have defined -mod Sep 25, 2018

agnivade added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 25, 2018

agnivade added this to the Go1.12 milestone Sep 25, 2018

agnivade added the modules label Sep 25, 2018

andybons modified the milestones: Go1.12, Go1.13 Feb 12, 2019

bcmills mentioned this issue Mar 5, 2019

cmd/go: fmt always attempts to update module cache #30577

Closed

jayconrod mentioned this issue Mar 21, 2019

cmd/go: go fmt shouldn't send network request in module mode #30975

Closed

bcmills mentioned this issue Apr 13, 2019

cmd/cover: accept -mod=vendor as an explicit flag #31018

Closed

andybons mentioned this issue May 13, 2019

cmd/fmt: tries to download dependencies #31976

Closed

andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019

cpu mentioned this issue Jul 11, 2019

ci: enforce all files are gofmt'd. zmap/zcrypto#194

Closed

aarondl mentioned this issue Sep 2, 2019

cmd/go: The modules feature acts in surprising ways #34025

Closed

danp added a commit to danp/go that referenced this issue Oct 1, 2019

cmd/go: respect -mod flag in fmt

edd7538

Fixes golang#27841 Change-Id: Ifcfd938aff8680cf7b44dfc09fde01d6105345a0

katiehockman added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Oct 8, 2019

gopherbot closed this as completed in ed7e430 Oct 8, 2019

bcmills mentioned this issue Oct 11, 2019

cmd/go: "fmt" should support "-mod=vendor" #34838

Closed

agnivade mentioned this issue Oct 22, 2019

go fmt doesn't work with vendoring mode enabled #35076

Closed

jkohen added a commit to Stackdriver/stackdriver-prometheus-sidecar that referenced this issue Oct 28, 2019

Invoke go fmt with mod=vendor

c62db9d

This removes network loads until `go fmt` stops trying to download those resources. golang/go#27841 has more information.

jkohen mentioned this issue Oct 28, 2019

Avoid loading resources from the network on make format Stackdriver/stackdriver-prometheus-sidecar#192

Merged

golang locked and limited conversation to collaborators Oct 7, 2020

gopherbot added the FrozenDueToAge label Oct 7, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/go: fmt does not respect or have defined -mod #27841

cmd/go: fmt does not respect or have defined -mod #27841

emikalendra commented Sep 25, 2018

agnivade commented Sep 25, 2018

myitcv commented Sep 25, 2018

emikalendra commented Sep 25, 2018

myitcv commented Sep 25, 2018

emikalendra commented Sep 25, 2018

rsc commented Oct 25, 2018

coolaj86 commented Mar 25, 2019

gopherbot commented Oct 1, 2019

cmd/go: fmt does not respect or have defined -mod #27841

cmd/go: fmt does not respect or have defined -mod #27841

Comments

emikalendra commented Sep 25, 2018

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

agnivade commented Sep 25, 2018

myitcv commented Sep 25, 2018

emikalendra commented Sep 25, 2018

myitcv commented Sep 25, 2018

emikalendra commented Sep 25, 2018

rsc commented Oct 25, 2018

coolaj86 commented Mar 25, 2019

gopherbot commented Oct 1, 2019

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

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