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: Empty go.mod after vgo build #24038

Closed
nicpottier opened this issue Feb 22, 2018 · 6 comments
Closed

x/vgo: Empty go.mod after vgo build #24038

nicpottier opened this issue Feb 22, 2018 · 6 comments
Labels
FrozenDueToAge
Milestone
vgo

Comments

@nicpottier
Copy link

nicpottier commented Feb 22, 2018 •
edited

Very excited by the direction vgo is going, kudos on that and on the thoughtful explanation of the ideas and implementations in Russ's post.

Not sure if I'm doing something wrong, but just tried out vgo on a project of mine after blowing away my vendor directory and it isn't building my go.mod as I would expect, it remains empty. I see one warning in there due to a package rename, but it seems to indicate it is moving / fixing it. (exit code id 1 however)

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

go version go1.10 darwin/amd64 vgo:2018-02-20.1

Does this issue reproduce with the latest release?

yes

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

amd64/darwin

What did you do?

  1. Grab one of my current go repos: https://github.com/nyaruka/courier, cd in courier dir.
  2. Delete vendor directory
  3. Touch go.mod
  4. Build
% vgo build
vgo: resolving import "github.com/garyburd/redigo/redis"
vgo: finding github.com/garyburd/redigo (latest)
vgo: adding github.com/garyburd/redigo v1.5.0
vgo: resolving import "github.com/go-chi/chi"
vgo: finding github.com/go-chi/chi (latest)
vgo: adding github.com/go-chi/chi v1.0.0
vgo: resolving import "github.com/lib/pq"
vgo: finding github.com/lib/pq (latest)
vgo: adding github.com/lib/pq v0.0.0-20180201184707-88edab080323
vgo: resolving import "github.com/koding/multiconfig"
vgo: finding github.com/koding/multiconfig (latest)
vgo: adding github.com/koding/multiconfig v0.0.0-20171124222453-69c27309b2d7
vgo: resolving import "github.com/aws/aws-sdk-go/aws"
vgo: finding github.com/aws/aws-sdk-go (latest)
vgo: adding github.com/aws/aws-sdk-go v1.13.2
vgo: resolving import "gopkg.in/guregu/null.v3"
vgo: finding gopkg.in/guregu/null.v3 (latest)
vgo: adding gopkg.in/guregu/null.v3 v1.3.0-gopkgin-v3.3.0
vgo: resolving import "github.com/sirupsen/logrus"
vgo: finding github.com/sirupsen/logrus (latest)
vgo: adding github.com/sirupsen/logrus v1.0.4
vgo: resolving import "github.com/nyaruka/gocommon/urns"
vgo: finding github.com/nyaruka/gocommon (latest)
vgo: adding github.com/nyaruka/gocommon v0.0.0-20180220182945-c3bea84b51d0
vgo: resolving import "github.com/satori/go.uuid"
vgo: finding github.com/satori/go.uuid (latest)
vgo: adding github.com/satori/go.uuid v1.2.0
vgo: resolving import "gopkg.in/go-playground/validator.v9"
vgo: finding gopkg.in/go-playground/validator.v9 (latest)
vgo: adding gopkg.in/go-playground/validator.v9 v1.11.0-gopkgin-v9.11.0
vgo: resolving import "golang.org/x/net/context"
vgo: finding golang.org/x/net (latest)
vgo: adding golang.org/x/net v0.0.0-20180218175443-cbe0f9307d01
vgo: resolving import "github.com/pressly/chi"
vgo: import "github.com/nyaruka/courier" ->
	import "github.com/go-chi/chi/middleware" ->
	import "github.com/pressly/chi": module path of repo is github.com/go-chi/chi, not github.com/pressly/chi (moved)
vgo: resolving import "github.com/BurntSushi/toml"
vgo: finding github.com/BurntSushi/toml (latest)
vgo: adding github.com/BurntSushi/toml v0.3.0
vgo: resolving import "github.com/fatih/camelcase"
vgo: finding github.com/fatih/camelcase (latest)
vgo: adding github.com/fatih/camelcase v0.0.0-20171027104257-44e46d280b43
vgo: resolving import "github.com/fatih/structs"
vgo: finding github.com/fatih/structs (latest)
vgo: adding github.com/fatih/structs v1.0.0
vgo: resolving import "gopkg.in/yaml.v2"
vgo: finding gopkg.in/yaml.v2 (latest)
vgo: adding gopkg.in/yaml.v2 v0.0.0-20180109114331-d670f9405373
vgo: resolving import "golang.org/x/crypto/ssh/terminal"
vgo: finding golang.org/x/crypto (latest)
vgo: adding golang.org/x/crypto v0.0.0-20180219163459-432090b8f568
vgo: resolving import "golang.org/x/sys/unix"
vgo: finding golang.org/x/sys (latest)
vgo: adding golang.org/x/sys v0.0.0-20180202135801-37707fdb30a5
vgo: resolving import "github.com/nyaruka/phonenumbers"
vgo: finding github.com/nyaruka/phonenumbers (latest)
vgo: adding github.com/nyaruka/phonenumbers v0.0.0-20180208145444-15aafd6b263c
vgo: resolving import "github.com/go-playground/universal-translator"
vgo: finding github.com/go-playground/universal-translator (latest)
vgo: adding github.com/go-playground/universal-translator v0.16.0

What did you expect to see?

Resolved dependencies in go.mod.

Note that one thing I'm noticing here is that the "default" of a v1 module is going to make transitioning to vgo a bit painful. It would be really nice if the behavior of importing the latest version of a module defaulted to the latest MAJOR version on first resolve (with the appropriate rewrites of import statements). For example, in this case I believe the failure is due to some bad naming in the v1 version of go-chi, which is now on v3 and which I believe has those naming errors fixed. I don't believe I would have any error at all if the default behavior was to pull in the last MAJOR version instead of the last V1 version.

At the very least it would be super useful to have the update command have a switch to allow moving to the latest version. (and doing the import rewrites for you)

What did you see instead?

% cat go.mod
module "github.com/nyaruka/courier
@gopherbot gopherbot added this to the vgo milestone Feb 22, 2018
@josler
Copy link

josler commented Feb 22, 2018

With rewriting the imports for this dependency in my own app to be github.com/go-chi/chi/v3, this still doesn't work as it resolves to v1.0.0:

vgo: resolving import "github.com/go-chi/chi/v3"
vgo: finding github.com/go-chi/chi (latest)
vgo: adding github.com/go-chi/chi v1.0.0
...
	import "github.com/go-chi/chi/v3" [/Users/jamieosler/go/src/v/github.com/go-chi/chi@v1.0.0/v3]: open /Users/jamieosler/go/src/v/github.com/go-chi/chi@v1.0.0/v3: no such file or directory

From reading around, I think this would be resolved if go-chi/chi had a go.mod file under a v3 tag, and internally imported things as chi/v3. Either way, it seems really hard to get the latest major version of a dependency installed, especially when they don't have the go.mod file.

@kardianos
Copy link
Contributor

You have an error in the dependency lookup:

vgo: import "github.com/nyaruka/courier" ->
	import "github.com/go-chi/chi/middleware" ->
	import "github.com/pressly/chi": module path of repo is github.com/go-chi/chi, not github.com/pressly/chi (moved)

Currently when any error happens the go.mod file is not touched. vgo needs to be picky about import paths because it embeds them into the binary and we can record the hashes. I think this is working as intended.

@kardianos
Copy link
Contributor

This is a duplicate of #23977 (version > 1 need import path changes) and #23974 (does not follow redirects).

@josler
Copy link

josler commented Feb 22, 2018

@kardianos does it follow then that it's by design that vgo cannot use a "latest" major version of a dependency if that dependency does not have a go.mod file?

eg:

  1. Dependency A has a v1.0.0 tag, v2.0.0 tag, v3.0.0 tag (but no go.mod anywhere)
  2. Try to import dependency A, works! Get v1.0.0 though
  3. Try to import dependency A/v3 (with the correct import path), doesn't work! Finds (latest) but imports 1.0.0.

I think this is a subtly different issue from the linked one (version > 1 need import path changes), even with import path changes you can't get a later version if that dependency does not use mod.go, so effectively you're unable to use that library directly.

@kardianos
Copy link
Contributor

@josler There are a few things here. There are both confirmed and potential issues with the vgo implementation. These are the aspects of the issue that I linked to other issues.

The issue you brought up is just the design of vgo and isn't an issue (but with real impact!). There is discussion of that on mailing lists and other issues, but if we discuss that it should be directed at the design specifically and this is a general issue.

@nicpottier
Copy link
Author

@josler FYI, I did get go-chi working with a require that looks like the below (and without changing any of my imports)

require(
    "github.com/go-chi/chi" v0.0.0-20180202194135-e223a795a06a
)

With that everything works great.

@golang golang locked and limited conversation to collaborators Feb 23, 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
@josler @nicpottier @kardianos @gopherbot