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

x/vgo: decide how much to support gopkg.in #24099

Closed
rogpeppe opened this issue Feb 24, 2018 · 12 comments

Comments

@rogpeppe
Copy link
Contributor

commented Feb 24, 2018

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

go version devel +104445e Wed Feb 7 19:22:09 2018 +0000 linux/amd64 vgo:2018-02-20.1

What did you do?

% cat go.mod
module "github.com/rogpeppe/xx"

require "gopkg.in/yaml.v2" v2.1.0
% vgo build
vgo: errors parsing go.mod:
/tmp/xx/go.mod:3: invalid module: gopkg.in/yaml.v2 should be v1, not v2 (v2.1.0)

If I change the module name in the requirements to "gopkg.in/yaml/v2", I see this output:

% vgo build
vgo: finding gopkg.in/yaml/v2 v2.1.0
vgo: gopkg.in/yaml/v2: invalid gopkg.in/ path: "gopkg.in/yaml/v2"
vgo: finding gopkg.in/yaml/v2 v2.1.0
vgo: gopkg.in/yaml/v2: invalid gopkg.in/ path: "gopkg.in/yaml/v2"
vgo: invalid gopkg.in/ path: "gopkg.in/yaml/v2"

@gopherbot gopherbot added this to the vgo milestone Feb 24, 2018

@rogpeppe

This comment has been minimized.

Copy link
Contributor Author

commented Feb 24, 2018

OK, I see what's happening now. It's not grokking the major-version-in-path of gopkg.in.
As an example, if I run vgo build on this program:

package main // import "github.com/rogpeppe/xx"

import (
	_ "gopkg.in/juju/charm.v4"
	_ "gopkg.in/juju/charm.v5"
	_ "gopkg.in/juju/charm.v6"
)

func main() {
}

I get this go.mod file:

module "github.com/rogpeppe/xx"

require (
	"github.com/juju/names" v0.0.0-20180129205841-f9b5b8b7614d
	"gopkg.in/juju/charm.v4" v0.0.0-20150410205938-af4be7b079ac
	"gopkg.in/juju/charm.v5" v0.0.0-20161109084014-949f52b3948c
	"gopkg.in/juju/charm.v6" v0.0.0-20180119231043-96786fc3f869
	"gopkg.in/yaml.v1" v0.0.0-20140924161607-9f9df34309c0
)

So I titled this issue wrong; it is possible to use gopkg.in with a major version > 1, although the behaviour is still not correct.

Interestingly, the go.mod file does not contain all the dependencies that I'd expect. For example, it contains gopkg.in/yaml.v1 (used by gopkg.in/juju/charm.v4) but not gopkg.in/yaml.v2 (used by gopkg.in/juju/charm.v6); it contains github.com/juju/names but not gopkg.in/juju/names.v2).

@rogpeppe rogpeppe changed the title x/vgo: cannot use gopkg.in with major version > 1 x/vgo: support gopkg.in major versions properly Feb 24, 2018

@tgulacsi

This comment has been minimized.

Copy link

commented Feb 24, 2018

require "gopkg.in/yaml.v2/v2"

works, sort of - it still includes the "gopkg.in/yaml.v2 v1.1.0-gopkg-v2.1.0" - see #24094

@rsc

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2018

support gopkg.in major versions properly

"Properly" is a loaded word, but it should work at least a little better than it does right now. In the original case the v2.1.0 should probably just be rewritten transparently to v1.1.0-gopkgin-v2.1.0, because we know this is gopkg.in.

I'm going to leave this bug open to track deciding what level of gopkg.in support we want. Maybe we should actually just allow v2.1.0 instead of the funny pseudo-version.

Interestingly, the go.mod file does not contain all the dependencies that I'd expect.

It contains a simplified list of dependencies, omitting those implied by the ones already listed. Because charm.v6's dependencies.tsv lists the exact version of gopkg.in/yaml.v2 that the build chose, it lists charm.v6 in the go.mod and stops there.

@rsc rsc changed the title x/vgo: support gopkg.in major versions properly x/vgo: decide how much to support gopkg.in Mar 30, 2018

@rsc rsc added the NeedsDecision label Mar 30, 2018

@gopherbot

This comment has been minimized.

Copy link

commented Apr 18, 2018

Change https://golang.org/cl/107658 mentions this issue: cmd/go/internal/modfetch: make gopkg.in support more seamless

@kron4eg

This comment has been minimized.

Copy link

commented Apr 25, 2018

After initial vgo build and go.mod (from empty state) generation, I get

gopkg.in/yaml.v2 v2.2.1

in go.mod file (which is expected now), on the second vgo build try error is reported:

invalid module: gopkg.in/yaml.v2 should be v1, not v2 (v2.2.1)
@primalmotion

This comment has been minimized.

Copy link

commented Apr 29, 2018

this is still happening to me

vgo build ./...
...
vgo: parsing downloaded go.mod: go.mod:22: invalid module: gopkg.in/yaml.v2 should be v1, not v2 (v2.0.0-20160301204022-a83829b6f129)
@markbates

This comment has been minimized.

Copy link

commented Apr 29, 2018

Agreed still doesn't work for me either

module github.com/gobuffalo/pop

require (
	github.com/cockroachdb/cockroach-go v0.0.0-20180212155653-59c0560478b7
	github.com/fatih/color v1.6.0
	github.com/go-sql-driver/mysql v1.0.3
	github.com/gobuffalo/envy v1.6.2
	github.com/gobuffalo/packr v1.11.0
	github.com/gobuffalo/uuid v1.2.0
	github.com/gobuffalo/validate v1.0.0
	github.com/jmoiron/sqlx v0.0.0-20180406164412-2aeb6a910c2b
	github.com/joho/godotenv v1.2.0
	github.com/lib/pq v0.0.0-20180327071824-d34b9ff171c2
	github.com/markbates/going v0.0.0-20170113214412-0576708c56ce
	github.com/markbates/inflect v0.0.0-20180405204719-fbc6b23ce49e
	github.com/mattn/anko v0.0.3
	github.com/pkg/errors v0.8.0
	golang.org/x/net v0.0.0-20180420171651-5f9ae10d9af5
	golang.org/x/sync v0.0.0-20180314180146-1d60e4601c6f
	gopkg.in/yaml.v2 v2.2.1
)
vgo: errors parsing go.mod:
$GOPATH/src/github.com/gobuffalo/pop/go.mod:20: invalid module: gopkg.in/yaml.v2 should be v1, not v2 (v2.2.1)
@cmars

This comment has been minimized.

Copy link
Contributor

commented Apr 30, 2018

Can we reopen this issue? I'm seeing the same issue as @kron4eg above.

@ALTree ALTree reopened this Apr 30, 2018

@bpicode bpicode referenced this issue May 1, 2018
@keltia

This comment has been minimized.

Copy link

commented May 2, 2018

I get the same with yaml.v2; the initial go.mod file was generated by vgo build but after that, it fails with the above error. yaml.v2 has no tags, does not use semver or anything.

@coyle coyle referenced this issue May 2, 2018
@lelvisl

This comment has been minimized.

Copy link

commented May 4, 2018

same problem with elastic

module modulename

require (
	github.com/BurntSushi/toml v0.3.0
	github.com/beorn7/perks v0.0.0-20180321164747-3a771d992973
	github.com/garyburd/redigo v1.6.0
	github.com/go-redis/redis v0.0.0-20160126235308-877867d2845fbaf86798befe410b6ceb6f5c29a3
.....
	gopkg.in/olivere/elastic.v3 v1.0.73-gopkgin-v3.0.73
)
→ vgo build
vgo: errors parsing go.mod:
.../App/go.mod:26: invalid module: gopkg.in/olivere/elastic.v3 should be v1, not v3 (v3.0.73)

And if I remove line with elastic from go.mod it builds.

@illegalnumbers

This comment has been minimized.

Copy link

commented May 8, 2018

I also see this issue.

joshuarubin added a commit to joshuarubin/vgo that referenced this issue May 9, 2018
x/vgo: fix parsing of go.mod with packages from gopkg.in
This addresses an issue where Parsing of `go.mod` with modules from
`gopkg.in` fails. The `go.mod` file is produced automatically, so the
first time something like `vgo build` is run (before `go.mod` is
created), it succeeds, but the second time it is run, it fails.

This fixes the latest issues described in
golang/go#24099

The funcs `parseGopkgIn` and `dotV` were pulled in (and slightly
modified/simplified) from `vendor/cmd/go/internal/modfetch/gopkgin.go`.

I'm sure that this is not the best way to handle the special case of
`gopkg.in` (especially compared to the effort put into creating the
`VersionFixer`), but it's a starting point that has test cases that
prove the autogenerated `go.mod` file can't be parsed.

Fixes #24099

Signed-off-by: Joshua Rubin <joshua@rubixconsulting.com>
joshuarubin added a commit to joshuarubin/vgo that referenced this issue May 9, 2018
x/vgo: fix parsing of go.mod with packages from gopkg.in
This addresses an issue where Parsing of `go.mod` with modules from
`gopkg.in` fails. The `go.mod` file is produced automatically, so the
first time something like `vgo build` is run (before `go.mod` is
created), it succeeds, but the second time it is run, it fails.

This fixes the latest issues described in
golang/go#24099

The funcs `parseGopkgIn` and `dotV` were pulled in (and slightly
modified/simplified) from `vendor/cmd/go/internal/modfetch/gopkgin.go`.

I'm sure that this is not the best way to handle the special case of
`gopkg.in` (especially compared to the effort put into creating the
`VersionFixer`), but it's a starting point that has test cases that
prove the autogenerated `go.mod` file can't be parsed.

Fixes #24099

Signed-off-by: Joshua Rubin <joshua@rubixconsulting.com>
gopherbot pushed a commit to golang/vgo that referenced this issue May 10, 2018
x/vgo: Fix parsing of go.mod with packages from gopkg.in
This addresses an issue where Parsing of `go.mod` with modules from `gopkg.in` fails. The `go.mod` file is produced automatically, so the first time something like `vgo build` is run (before `go.mod` is created), it succeeds, but the second time it is run, it fails.

This fixes the latest issues described in golang/go#24099

The funcs `parseGopkgIn` and `dotV` were pulled in (and slightly modified/simplified) from `vendor/cmd/go/internal/modfetch/gopkgin.go`.

I'm sure that this is not the best way to handle the special case of `gopkg.in` (especially compared to the effort put into creating the `VersionFixer`), but it's a starting point that has test cases that prove the autogenerated `go.mod` file can't be parsed.

Fixes #24099

Change-Id: Ie0bee2a50b330a9f85c1459ff6eb0bfa43058bf1
GitHub-Last-Rev: f608544
GitHub-Pull-Request: #4
Reviewed-on: https://go-review.googlesource.com/112277
Reviewed-by: Russ Cox <rsc@golang.org>
@rsc

This comment has been minimized.

Copy link
Contributor

commented May 10, 2018

Fixed by recent CL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.