dupe of #24585

The issue is that vgo doesn't let you use packages >v1 that doesn't have a go.mod file. And so if a package doesn't have a go.mod file it's supposed to be using v0.0.0-yyyymmddhhmmss-commit instead.

Closing as a dup of #24585.

the difference here is that here I don't even have a go.mod file so not sure where should I change this?

vgo build renders the same error without creating a go.mod file.

You can try forking github.com/djherbis/nio and adding a go.mod file till it's fixed
You can also try manually creating a go.mod file

It says

vgo: parsing downloaded go.mod:

It looks like a dependency of yours is hitting #24585? But anyway when #24585 is fixed this should also fix your build, and if that's the case I'm not sure this issue adds anything over #24585.

the strange thing is that I can't even find anything in prometheus importing this package
https://github.com/prometheus/prometheus/search?utf8=%E2%9C%93&q=github.com%2Fdjherbis%2Fnio&type=

prometheus already uses vendoring so it should be in the vendored directory.

It's github.com/oklog/oklog that imports it:

https://github.com/oklog/oklog/blob/5716cd64ee1c07e5b22113fb28d6121f80b8a24a/Gopkg.toml#L7

So although prometheus only uses github.com/oklog/oklog/pkg/group and not github.com/oklog/oklog it seems that vgo matches against the root package.

Isn't this an incorrect behaviour? since the github.com/djherbis/nio would never be actually used.

vgo matches modules. (a module is "a collection of packages versioned as a unit"). In this case, github.com/oklog/oklog is a module.

@AlexRouSg Hey, I'm the author of djherbis/nio.

I've not used vgo, why would my package need to be 'fixed' with a go.mod file if I don't use vgo?

@djherbis the answer won't fit on a single page :)

I recommend watching https://www.youtube.com/watch?v=sbrZfPgNmfw
or reading the vgo blogpost which goes into detailed explanation about versioning and the need for vgo which will become eventually the official go command.

@djherbis I think you've misunderstood my posts? I said there is a bug regarding packages using v2+ and if he didn't want to wait for the fix then he could either add a go.mod file to your package or manually create a go.mod file in his package with the correct version format since vgo is failing to create one.

tl;dr; do I need to do something to my repo so people can use it, specifically vgo users?

@AlexRouSg I'm sure I've misunderstood, when you said 'wait for the fix' it seemed to me like you might have been referring to my package, whereas now I'm guessing you mean a fix in vgo?

@krasi-georgiev I think I understand the need for versioning/package management etc., though I haven't looked into vgos solution specifically (thanks for the links though). It seemed odd to me that my package/repo would need to be modified, just because a package which imports mine uses vgo. That would seem to pose a large burden to upgrade all existing Go repos to use vgo, if they are depended upon by a repo that uses vgo. Is this the case?

in your particular case it is a bug in vgo which should be fixed soon.

nothing needed from your side.
Thanks

@djherbis Yes I meant vgo.

If you want to directly support vgo then all you have to do is go get -u golang.org/x/vgo (you must be using go >= 1.10) then vgo build your package then it should generate a go.mod file which you can commit (you need to do this for every major version >1). Also you would then have to make sure you have the proper git tags in the format vX.Y.Z where X Y Z are positive integers.

Supporting vgo also means v1 and v2+ can/will and must live together. So if there are any changes you have to take to allow that then you should make those changes.

Since the bug tracker is not for questions or discussions please post further questions in the proper places. https://github.com/golang/go/wiki/Questions

Also read the blogs to get a better understanding of vgo https://research.swtch.com/vgo

This has reappeared somehow.

$ vgo build ./...
vgo: errors parsing go.mod:
/usr/local/google/home/cflewis/src/go/src/github.com/google/go-cloud/go.mod:46: invalid module: gopkg.in/yaml.v2 should be v1, not v2 (v2.2.1)

gopkg.in/yaml.v2 does have a go.mod file.

The go.mod file entry for this looks like gopkg.in/yaml.v2 v2.2.1

This issue was fixed by CL 112277.