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

x/vgo: transitive dependencies should not appear in the go.mod file #25412

Closed
ufoscout opened this issue May 16, 2018 · 3 comments
Closed

x/vgo: transitive dependencies should not appear in the go.mod file #25412

ufoscout opened this issue May 16, 2018 · 3 comments
Labels
FrozenDueToAge
Milestone
vgo

Comments

@ufoscout
Copy link

ufoscout commented May 16, 2018 •
edited

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

go version go1.10.2 linux/amd64

Does this issue reproduce with the latest release?

Reproducible with vgo:2018-02-20.1

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ufo/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/ufo/workspaces/go"
GORACE=""
GOROOT="/home/ufo/Programs/go"
GOTMPDIR=""
GOTOOLDIR="/home/ufo/Programs/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
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-build204477034=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I migrated a sample application from dep to vgo. The original dep configuration file was as simple as:

[[constraint]]
  name = "github.com/spf13/viper"
  version = "v1.0.0"

I manually created this equivalent go.mod file:

module github.com/ufoscout/go-up/examples/viper

require github.com/spf13/viper v1.0.0

However, when I launched "vgo build", the go.mod file was silently modified to the following one that contains all the transitive dependencies:

module github.com/ufoscout/go-up/examples/viper

require (
	github.com/fsnotify/fsnotify v1.4.7
	github.com/hashicorp/hcl v0.0.0-20180404174102-ef8a98b0bbce
	github.com/magiconair/properties v1.8.0
	github.com/mitchellh/mapstructure v0.0.0-20180511142126-bb74f1db0675
	github.com/pelletier/go-toml v1.1.0
	github.com/spf13/afero v1.1.0
	github.com/spf13/cast v1.2.0
	github.com/spf13/jwalterweatherman v0.0.0-20180109140146-7c0cea34c8ec
	github.com/spf13/pflag v1.0.1
	github.com/spf13/viper v1.0.0
	golang.org/x/sys v0.0.0-20180514143608-7c87d13f8e83
	golang.org/x/text v0.3.0
	gopkg.in/yaml.v2 v2.2.1
)

The only direct dependency of my code is "github.com/spf13/viper v1.0.0"; however, it is completely impossible to guess it in the middle of that huge list.

What did you expect to see?

I expected the go.mod file to not include the transitive dependencies of my code.
This is the standard behavior of any other build manager used by my company (i.e. maven, gradle, cargo, npm, dep).
Finally, I find extremely scaring that the go.mod file is silently modified without asking or informing me.

What did you see instead?

The go.mod file is silently changed and it now contains a confusing flat list of libraries. Consequently, it is nearly impossible to understand what I am directly using; so simple operations (e.g. updating a direct dependency) becomes really hard.

This was an experiment to evaluate vgo, but following this result, my company decided to stay with dep which we feel is less invasive and simpler than vgo. In addition, it gives us the feeling that we, and not the tool, are in control of our configuration files.
@ufoscout ufoscout changed the title VGO: transitive dependencies should not appear in the go.mod file x/vgo: transitive dependencies should not appear in the go.mod file May 16, 2018
@gopherbot gopherbot added this to the vgo milestone May 16, 2018
@OneOfOne OneOfOne mentioned this issue May 16, 2018
Closed
@kardianos
Copy link
Contributor

A few points about vgo's design:

  • vgo is designed to modify mod.go as requested from commands such as vgo get. This is similar to how goimports will re-write or update go source files.
  • vgo is designed so that running vgo build twice will always produce the same binary. A few observations: no lock file (go.mod or other lock file) exists in viper. Thus in order to achieve the previously stated goal, vgo must include these dependencies in this mod.go.
  • vgo doesn't have a lock file. In other words, it uses MVS to combine each mod.go into a set of "locked" dependencies. In this case, because you viper lacks such a mod.go file, it requires all transitive dependencies to be included.

Due to these, I would encurage you to fork viper, include a mod.go file in that module, then reference that fork in mod.go. vgo shouldn't include those transitive dependencies in main repo if they are stated elsewhere (they still can be and the MVS will operate on it still if you need to bump a transitive dependency version).

What you are seeing is the intended behavior of vgo.

@myitcv
Copy link
Member

myitcv commented May 20, 2018 •
edited

@kardianos I think you meant s/mod.go/go.mod/ above, no?

@kardianos
Copy link
Contributor

Yes.

@golang golang locked and limited conversation to collaborators May 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
vgo
Development

No branches or pull requests
4 participants
@kardianos @ufoscout @myitcv @gopherbot