x/vgo: rewrite v2+.x.x pointing at non-module code to v0.0.0 pseudoversion #24056
Comments
|
Here's an example using https://github.com/dgrijalva/jwt-go, which has semver tags starting at package main
import (
"fmt"
jwt "github.com/dgrijalva/jwt-go"
)
func main() {
fmt.Printf("constant from jwt-go: %v\n", jwt.ValidationErrorMalformed)
}Manually adding the newest tagged version in From the article https://research.swtch.com/vgo-module I got the impression that repositories which do not yet have a Is my impression wrong, did I overlook something? Thank you very much @rsc for getting this discussion started! I'm excited about the upcoming changes! |
|
Yes this is exactly what I mean.
…On Sat, Feb 24, 2018 at 7:24 AM Alexander Neumann ***@***.***> wrote:
Here's an example using https://github.com/dgrijalva/jwt-go, which has
semver tags starting at v1.0.0 until v3.1.0, which is the latest version.
When this is used in a small sample program, e.g.
https://github.com/fd0/vgotest-issue-24056, vgo will select the (ancient)
tag v1.0.2:
package main
import (
"fmt"
jwt "github.com/dgrijalva/jwt-go"
)
func main() {
fmt.Printf("constant from jwt-go: %v\n", jwt.ValidationErrorMalformed)
}
$ vgo version
go version go1.10 linux/amd64 vgo:2018-02-20.1
$ cat go.mod
module "github.com/fd0/vgotest-issue-24056"
$ vgo build
vgo: resolving import "github.com/dgrijalva/jwt-go"
vgo: finding github.com/dgrijalva/jwt-go (latest)
vgo: adding github.com/dgrijalva/jwt-go v1.0.2
$ cat go.mod
module "github.com/fd0/vgotest-issue-24056"
require "github.com/dgrijalva/jwt-go" v1.0.2
Manually adding the newest tagged version in go.mod leads to the
described error that the /v3 path component in the import path is not
there:
$ cat go.mod
module "github.com/fd0/vgotest-issue-24056"
require "github.com/dgrijalva/jwt-go" v3.1.0
$ vgo build
vgo: errors parsing go.mod:
/home/fd0/shared/work/go/src/github.com/fd0/vgotest-issue-24056/go.mod:3: invalid module: github.com/dgrijalva/jwt-go should be v1, not v3 (v3.1.0)
From the article https://research.swtch.com/vgo-module I got the
impression that repositories which do not yet have a go.mod are treated
the same way by vgo as Go does today, but in this case it seems to be
different. Is it maybe a good idea to not require a semantic import path
component when no go.mod file is there? I think this is what @docmerlin
<https://github.com/docmerlin> refers to in this issue (please correct me
if I'm wrong).
Is my impression wrong, did I overlook something?
Thank you very much @rsc <https://github.com/rsc> for getting this
discussion started! I'm excited about the upcoming changes!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#24056 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABLfWyp81WOQiw69MhMwLpr3RqJLYDexks5tYA15gaJpZM4SQel4>
.
|
|
For the record, for direct dependencies this can be resolved by manually pinning the version of I've found the timestamp by checking out the tag, and then using Is there a way to do this automatically? How can I do this with indirect dependencies? I've added a second sample repository, https://github.com/fd0/vgotest-issue-24056-indirect The program there imports |
|
For the record: It's not necessary to find out the timestamp of the git commit by hand, we can just insert the commit ID into the |
rsc
changed the title
|
If go.mod says |
rsc
added
the
NeedsFix
|
Change https://golang.org/cl/107660 mentions this issue: |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?vgo
Does this issue reproduce with the latest release?
no just with vgo
What did you do?
vgo getbreaks the build of anything that has a dependency that is using tags for semantic versioning. The assumption on imports without an explicit dependency meaning v0-v1 breaks things.If your package already use semantic versioning in git tags, anything that imports your app and has been keeping up to date with master (or with the latest tag) will suddenly break.
A possible workaround to minimize the breaking is to make
import "github.com/foo/bar"assume a fallback that is less likely to break. Assuming it means master (if there are no semvar tags), or latest required semvar if it is being fetched as part of a build, or something similar is far less likely to break packages. This would also require v0-v1 being required to be explicit, if there are any semvar tags with major version greater than v1 in the git repo.What did you expect to see?
No breaking changes in go1.
What did you see instead?
A majorly breaking change in go1. Lots of things will become un-vgo-getable.
The text was updated successfully, but these errors were encountered: