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: vgo build and vgo mod -sync produce different list of dependencies #25971

Closed
dlsniper opened this issue Jun 20, 2018 · 5 comments
Closed

x/vgo: vgo build and vgo mod -sync produce different list of dependencies #25971

dlsniper opened this issue Jun 20, 2018 · 5 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
vgo

Comments

@dlsniper
Copy link
Contributor

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

go version go1.10.3 linux/amd64
golang/vgo@f574d31

Does this issue reproduce with the latest release?

yes

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

cross-platform issue

What did you do?

In the following case, having the files outside of GOPATH:

  • main.go
package main

import "github.com/gorilla/mux"

func main() {
	m := mux.NewRouter()
	_ = m
}
  • go.mod
module awesomevgoProject

Then run vgo build. Cleanup the go.mod file to the one in the issue and now run vgo mod -sync.

What did you expect to see?

  • vgo build produces the following go.mod
module awesomevgoProject

require github.com/gorilla/mux v1.6.2
  • vgo mod -sync produces the following go.mod
module awesomevgoProject

require (
	github.com/gorilla/context v1.1.1
	github.com/gorilla/mux v1.6.2
)

What did you see instead?

I expect the file to be similar in both cases.
And given that vgo build produces a working code, I expect that vgo build is the minimal source of truth in this case.

Maybe this works as expected but in this case, more documentation would be useful as vgo build will be significantly faster than vgo mod -sync in case of many dependencies that need to be downloaded if the pattern can replicate in larger projects.
@gopherbot gopherbot added this to the vgo milestone Jun 20, 2018
@bcmills
Copy link
Contributor

bcmills commented Jun 20, 2018

The difference here is in the build tags: mux/context_gorilla.go imports github.com/gorilla/context, but is guarded by a !go1.7 build tag. When you invoke vgo build, it is probably only updating the requirements that are affected by the current tags.

In contrast, vgo mod -sync intentionally ignores build tags: the go.mod file is also the input to vgo vendor, which is the support path for users on older versions of the go command.

@bcmills bcmills added NeedsFix The path to resolution is known, but the work has not been done. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed NeedsFix The path to resolution is known, but the work has not been done. labels Jun 20, 2018
@dlsniper
Copy link
Contributor Author

Thank you for the update.

In this case, what is preferred to invoke? vgo build or vgo mod -sync?

Also, in the case of third-party tooling that wants to support users work on vgo enabled apps, what is preferred to run?

I understand the difference in these run modes but I think that in order to minimize the friction with developers, both commands should behave the same.
Imagine a case where a dependency will be present or not based on the user's operating system. In this case, it could potentially create unnecessary churn and additional confusion for reviewers as to why the go.mod file changes between users.

@bcmills
Copy link
Contributor

bcmills commented Jun 20, 2018

To be clear: I'm not saying that vgo build and vgo mod -sync should produce different results. I'm just explaining the likely reason that they do today.

(I tend to agree with you that they should be equivalent, but that invariant has a non-trivial cost. I'm curious to find out @rsc's thoughts on the matter.)

@kardianos
Copy link
Contributor

They should not be equivalent. go build should be lazy and do minimal work for that GOOS, GOARCH, and tag-set.

go mod x is for managing the mod requirements regardless of the current system setup. This is similar to how govendor works. This attribute is important.

One project I work on I develop on Linux and deploy to windows. I don't want my deploy step pulling down extra un-reviewed deps. So when I update dependencies they ignore current GOOS values. This is also why govendor had to reimplement package discovery.

Issue #25873 is about limiting the scope of the mod subcommand, but would not affect go build.

@bcmills
Copy link
Contributor

bcmills commented Jun 21, 2018

I chatted a bit about this with Russ this morning, and his interpretation agrees with @kardianos' comment: vgo build does the minimal work needed to satisfy the imports of the requested packages for that particular build invocation. So I think this is working as intended.

Personally, I would recommend vgo build as the default during development, plus a vgo mod -sync in any commit to be tagged for release.

@bcmills bcmills closed this as completed Jun 21, 2018
@dlsniper dlsniper mentioned this issue Jul 4, 2018
Closed
@thepudds thepudds mentioned this issue Jul 24, 2018
Closed
@thepudds thepudds mentioned this issue Sep 2, 2018
Closed
@bltavares bltavares mentioned this issue Mar 20, 2019
Merged
@golang golang locked and limited conversation to collaborators Jun 21, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
vgo
Development

No branches or pull requests
4 participants
@dlsniper @kardianos @bcmills @gopherbot