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: vgo does not fix the timestamp in a pseudo-version #24369
Comments
Thank you! Using that row of zeros makes it a lot easier to specify the date in advance. I'm not even sure in which timezone I had to specify the string after I had extracted it from a given commit info. So in my opinion the actual check should only be introduced after we have an easy and documented way to extract the pseudoversion from a given package/module without having to do the |
Run "go build" and then "cat go.mod". What does it say? It should be updated to have the right timestamp. For that matter, even if you'd written:
it's supposed to get updated to turn into the right pseudo-version. Can you let me know if that's what you're seeing? |
In my case it was Then I searched for ways to force another git-ref. So I tried But this behaviour is not documented (or at least not easily discoverable), therefore my confusion. Of course I am aware of the fact, that But as we are talking about it, is it possible to use arbitrary refs (branch, tag, commit) in a human readable way? How does this play with other VCS like SVN? |
Here are the results of running Before running the commands, here are
and
Then, I run
Notably, if I instead write my
then after running
|
Thanks @enocom. Vgo should be fixing the bad timestamp the same way it fixes the commit. |
@rsc Are you interested in contributions for this issue? I imagine vgo is still under heavy development and I don't want to interfere with the work. |
Feel free to send a CL. |
Change https://golang.org/cl/106799 mentions this issue: |
Change https://golang.org/cl/107655 mentions this issue: |
CL 106799 changed the mod file parser to be call the fixer function for every module, version pair, not just the ones with non-canonical semantic versions. Of course, we don't want to hit the network for every line of every go.mod, when most of them are fine. Skip the network for the ones that are syntactically OK, including proper matching between the module path and major version. For golang/go#24369. Change-Id: Id101d8f3c10bccde8a755ae734dbacf4d0a36f8d Reviewed-on: https://go-review.googlesource.com/107655 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
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
)?What did you do?
Here is a
go.mod
which pulls in gorilla/mux:What did you expect to see?
I would expect
vgo build
to fail to find the specified version ofgorilla/mux
since the timestamp does not match that of the commit.In Defining Go Modules, it says:
What did you see instead?
vgo build
works without a problem and produces a functioning binary.The text was updated successfully, but these errors were encountered: