persistent-https: add go.mod to fix compile
PATCH 1/1 persistent-https: add go.mod to fix compile
From: Dominyk Tiller <[email protected]>
GOPATH-based builds and non module-aware builds are being deprecated by golang upstream, which currently causes this to fail. This adds a barebones mod file to fix the build.
The persistent-https code hasn't been touched for a long time but I assume this is preferable to simply removing it from the codebase.
Before this change:
```
case $(go version) in \
"go version go"1.[0-5].*) EQ=" " ;; *) EQ="=" ;; esac && \
go build -o git-remote-persistent-https \
-ldflags "-X main._BUILD_EMBED_LABEL${EQ}"
go: cannot find main module, but found .git/config in ../git
to create a module there, run:
cd ../.. && go mod init
make: *** [git-remote-persistent-https] Error 1
```Ref: https://blog.golang.org/go116-module-changes.
---
persistent-https: add go.mod to fix compile
GOPATH-based builds and non module-aware builds are being deprecated by golang upstream, which currently causes this to fail. This adds a barebones mod file to fix the build.
The persistent-https code hasn't been touched for a long time but I assume this is preferable to simply removing it from the codebase. Before this change:
case $(go version) in \
"go version go"1.[0-5].*) EQ=" " ;; *) EQ="=" ;; esac && \
go build -o git-remote-persistent-https \
-ldflags "-X main._BUILD_EMBED_LABEL${EQ}"
go: cannot find main module, but found .git/config in ../git
to create a module there, run:
cd ../.. && go mod init
make: *** [git-remote-persistent-https] Error 1
Ref: https://blog.golang.org/go116-module-changes
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-989%2FDomT4%2Fgo_modules-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-989/DomT4/go_modules-v1
Pull-Request: https://github.com/git/git/pull/989
contrib/persistent-https/go.mod | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 contrib/persistent-https/go.mod
contrib/persistent-https/go.mod new file +3 -0
@@ -0,0 +1,3 @@ +module github.com/git/git/contrib/persistent-https + +go 1.16
base-commit: 9198c13e34f6d51c983b31a9397d4d62bc2147ac
Signature · 1 line
gitgitgadget
Quoted 10 lines · Dominyk Tiller via GitGitGadget
From: Dominyk Tiller <[email protected]>
GOPATH-based builds and non module-aware builds are being deprecated by golang upstream, which currently causes this to fail. This adds a barebones mod file to fix the build.
The
persistent-httpscode hasn't been touched for a long time but I assume this is preferable to simply removing it from the codebase.Before this change:
Quoted 10 lines
```
case $(go version) in \
"go version go"1.[0-5].*) EQ=" " ;; *) EQ="=" ;; esac && \
go build -o git-remote-persistent-https \
-ldflags "-X main._BUILD_EMBED_LABEL${EQ}"
go: cannot find main module, but found .git/config in ../git
to create a module there, run:
cd ../.. && go mod init
make: *** [git-remote-persistent-https] Error 1
```With which version of go? Any recent version would fail the same way, or only 1.16 and later?
contrib/persistent-https/go.mod line 3
Quoted 11 lines
Ref: https://blog.golang.org/go116-module-changes.
contrib/persistent-https/go.mod new file +3
-0@@ -0,0 +1,3 @@ +module github.com/git/git/contrib/persistent-https + +go 1.16
Can I ask what is affected by this 1.16 version number? Do the users have to use 1.16 and nothing older or newer?
As a non Go user, I am trying to see if this change is "make it work for all users of reasonably new versions of Go" (if that is the case, what is the "reasonably new") or "make it work for those with 1.16, and everybody else should either install 1.16 or figure out their own solutions".
Thanks.
Junio C Hamano wrote on 30/03/2021 20:09:
Quoted 22 lines
Quoted 10 lines · Dominyk Tiller via GitGitGadget
From: Dominyk Tiller <[email protected]>
GOPATH-based builds and non module-aware builds are being deprecated by golang upstream, which currently causes this to fail. This adds a barebones mod file to fix the build.
The
persistent-httpscode hasn't been touched for a long time but I assume this is preferable to simply removing it from the codebase.Before this change:
Quoted 10 lines
``` case $(go version) in \ "go version go"1.[0-5].*) EQ=" " ;; *) EQ="=" ;; esac && \ go build -o git-remote-persistent-https \ -ldflags "-X main._BUILD_EMBED_LABEL${EQ}" go: cannot find main module, but found .git/config in ../git to create a module there, run: cd ../.. && go mod init make: *** [git-remote-persistent-https] Error 1 ```
Quoted 2 lines
With which version of go? Any recent version would fail the same way, or only 1.16 and later?
The link I referenced in the notes explains a little more in depth, but there's an environment variable you can use with 1.16 to temporarily mitigate the failure, i.e. export GO111MODULE=off, but regardless of the presence of that the lack of module-awareness will become a hard failure in Go 1.17. The lack of module awareness is only a failure on Go 1.16 and later. Module support was added in basic form as far back as Go 1.11, released late 2018.
Quoted 14 lines
contrib/persistent-https/go.mod line 3
Quoted 11 lines
Ref: https://blog.golang.org/go116-module-changes.
contrib/persistent-https/go.mod new file +3
-0@@ -0,0 +1,3 @@ +module github.com/git/git/contrib/persistent-https + +go 1.16Can I ask what is affected by this 1.16 version number? Do the users have to use 1.16 and nothing older or newer?
Quoted 7 lines
As a non Go user, I am trying to see if this change is "make it work for all users of reasonably new versions of Go" (if that is the case, what is the "reasonably new") or "make it work for those with 1.16, and everybody else should either install 1.16 or figure out their own solutions".
Thanks.
This is more thoroughly detailed here:
https://golang.org/ref/mod#go-mod-file-go, but essentially the version number was/is intended to be the minimum Go version the module is designed to work with. We could set it lower to play it safe if the Git project wishes, but to date there have been no backwards incompatibilities with the module system and the way we're using the module system is so basic I don't see any way we'd trigger the version-based behaviours detailed in the link above. For what it's worth testing locally against 1.15 it builds without issue, despite being a lower version number than specified in the string.
Dom
===
Quoted 53 lines · Dominyk Tiller
Junio C Hamano wrote on 30/03/2021 20:09:
Quoted 22 lines
Quoted 10 lines · Dominyk Tiller via GitGitGadget
From: Dominyk Tiller <[email protected]>
GOPATH-based builds and non module-aware builds are being deprecated by golang upstream, which currently causes this to fail. This adds a barebones mod file to fix the build.
The
persistent-httpscode hasn't been touched for a long time but I assume this is preferable to simply removing it from the codebase.Before this change:
Quoted 10 lines
``` case $(go version) in \ "go version go"1.[0-5].*) EQ=" " ;; *) EQ="=" ;; esac && \ go build -o git-remote-persistent-https \ -ldflags "-X main._BUILD_EMBED_LABEL${EQ}" go: cannot find main module, but found .git/config in ../git to create a module there, run: cd ../.. && go mod init make: *** [git-remote-persistent-https] Error 1 ```Quoted 2 lines
With which version of go? Any recent version would fail the same way, or only 1.16 and later?
The link I referenced in the notes explains a little more in depth, but there's an environment variable you can use with 1.16 to temporarily mitigate the failure, i.e.
export GO111MODULE=off, but regardless of the presence of that the lack of module-awareness will become a hard failure in Go 1.17. The lack of module awareness is only a failure on Go 1.16 and later. Module support was added in basic form as far back as Go 1.11, released late 2018.Quoted 14 lines
contrib/persistent-https/go.mod line 3
Quoted 11 lines
Ref: https://blog.golang.org/go116-module-changes.
contrib/persistent-https/go.mod new file +3
-0@@ -0,0 +1,3 @@ +module github.com/git/git/contrib/persistent-https + +go 1.16Can I ask what is affected by this 1.16 version number? Do the users have to use 1.16 and nothing older or newer?
Quoted 7 lines
As a non Go user, I am trying to see if this change is "make it work for all users of reasonably new versions of Go" (if that is the case, what is the "reasonably new") or "make it work for those with 1.16, and everybody else should either install 1.16 or figure out their own solutions".
Thanks.
Quoted 10 lines
This is more thoroughly detailed here:
https://golang.org/ref/mod#go-mod-file-go, but essentially the version number was/is intended to be the minimum Go version the module is designed to work with. We could set it lower to play it safe if the Git project wishes, but to date there have been no backwards incompatibilities with the module system and the way we're using the module system is so basic I don't see any way we'd trigger the version-based behaviours detailed in the link above. For what it's worth testing locally against 1.15 it builds without issue, despite being a lower version number than specified in the string.
I've done the same experiment with 1.15 before writing the message you are responding to.
It felt a bit of magic as I never expected 1.15 binary to anticipate what is in 1.16, or to be able to say that a version from the future (from 1.15 binary's point of view) has backward incompatible semantics to stop the use of the module (the reason why I used 1.15 was because it was readily available in Debian). Public documentation by Go folks that explain go.mod file format seems to use "go 1.12" in the examples everywhere, so it might be a sane version string to use?
In any case, explaining these things in this response is good, but eventually we need to make sure that the readers of the resulting commit would not have to ask the same question, without having to refer to external documentation.
Thanks.
Quoted 4 lines · Junio C Hamano
In any case, explaining these things in this response is good, but eventually we need to make sure that the readers of the resulting commit would not have to ask the same question, without having to refer to external documentation.
It might also be worthwhile -- for the non-Go readers -- for the commit message to mention that this addition of a go.mod file does not hinder those stuck with old pre-module versions of Go (it doesn't help them either, but that's less significant), thus this change does not require them to update to a modern version of Go (i.e. we're not raising the minimum required version).
Quoted 6 lines · Eric Sunshine
Quoted 4 lines · Junio C Hamano
In any case, explaining these things in this response is good, but eventually we need to make sure that the readers of the resulting commit would not have to ask the same question, without having to refer to external documentation.
Quoted 6 lines
It might also be worthwhile -- for the non-Go readers -- for the commit message to mention that this addition of a
go.modfile does not hinder those stuck with old pre-module versions of Go (it doesn't help them either, but that's less significant), thus this change does not require them to update to a modern version of Go (i.e. we're not raising the minimum required version).
Thanks for spelling out the most important part of what the readers should be able to read from the resulting commit. I agree that piece of information is a must.