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

rogpeppe · 2018-02-24T12:40:11Z

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"

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

rogpeppe · 2018-02-24T12:54:31Z

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).

tgulacsi · 2018-02-24T18:13:42Z

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 · 2018-03-30T16:12:00Z

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.

gopherbot · 2018-04-18T06:32:35Z

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

kron4eg · 2018-04-25T22:23:43Z

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 · 2018-04-29T08:09:43Z

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 · 2018-04-29T17:01:01Z

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 · 2018-04-30T12:41:53Z

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

keltia · 2018-05-02T18:32:58Z

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.

lelvisl · 2018-05-04T14:38:47Z

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 · 2018-05-08T21:29:39Z

I also see this issue.

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>

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 · 2018-05-10T18:15:44Z

Fixed by recent CL.

gopherbot added this to the vgo milestone Feb 24, 2018

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

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 added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Mar 30, 2018

rsc mentioned this issue Apr 2, 2018

cmd/go: does not recognize gopkg.in/foo.v2-unstable #23989

Closed

gopherbot closed this as completed in golang/vgo@84430ca Apr 25, 2018

rsc mentioned this issue Apr 25, 2018

cmd/go: add package version support to Go toolchain #24301

Closed

client9 mentioned this issue Apr 27, 2018

x/vgo: unclear error message with gopkg.in #25121

Closed

ALTree reopened this Apr 30, 2018

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

bpicode mentioned this issue May 1, 2018

vgo adoption? bpicode/fritzctl#135

Closed

coyle mentioned this issue May 2, 2018

Clean lint storj/storj#20

Merged

docwhat mentioned this issue May 8, 2018

x/vgo: get gopkg.in/yaml.v2 succeeds, but produces invalid go.mod #25243

Closed

joshuarubin mentioned this issue May 9, 2018

x/vgo: Fix parsing of go.mod with packages from gopkg.in golang/vgo#4

Closed

rsc mentioned this issue May 10, 2018

x/build/cmd/gerritbot: does not respect codereview.cfg for fixing commit messages #25337

Open

rsc closed this as completed May 10, 2018

roylee0704 mentioned this issue Jul 28, 2018

Update package:yaml in go.mod nicksnyder/go-i18n#116

Closed

VojtechVitek mentioned this issue Aug 20, 2018

Fix Go module path for v5 olivere/elastic#869

Merged

golang locked and limited conversation to collaborators Apr 3, 2020

gopherbot added the FrozenDueToAge label Apr 3, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

rogpeppe commented Feb 24, 2018

rogpeppe commented Feb 24, 2018

tgulacsi commented Feb 24, 2018

rsc commented Mar 30, 2018

gopherbot commented Apr 18, 2018

kron4eg commented Apr 25, 2018

primalmotion commented Apr 29, 2018 •

edited

markbates commented Apr 29, 2018

cmars commented Apr 30, 2018

keltia commented May 2, 2018

lelvisl commented May 4, 2018

illegalnumbers commented May 8, 2018

rsc commented May 10, 2018

Navigation Menu

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

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

Comments

rogpeppe commented Feb 24, 2018

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

What did you do?

rogpeppe commented Feb 24, 2018

tgulacsi commented Feb 24, 2018

rsc commented Mar 30, 2018

gopherbot commented Apr 18, 2018

kron4eg commented Apr 25, 2018

primalmotion commented Apr 29, 2018 • edited

markbates commented Apr 29, 2018

cmars commented Apr 30, 2018

keltia commented May 2, 2018

lelvisl commented May 4, 2018

illegalnumbers commented May 8, 2018

rsc commented May 10, 2018

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

primalmotion commented Apr 29, 2018 •

edited