-
Notifications
You must be signed in to change notification settings - Fork 853
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
Upgrade sops to go 1.13 #566
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm. I have the impression this is going to break a lot of people :( but I guess we have to rip off the bandaid at some point.
Codecov Report
@@ Coverage Diff @@
## develop #566 +/- ##
===========================================
+ Coverage 36.94% 37.11% +0.17%
===========================================
Files 21 21
Lines 2891 2891
===========================================
+ Hits 1068 1073 +5
+ Misses 1728 1724 -4
+ Partials 95 94 -1
Continue to review full report at Codecov.
|
My knowledge about Go modules is pretty much zero, but is there a way we could separate the versioning of the Go codebase from the versioning of the sops binary, which is effectively the only thing we actually version with semver? If we do that, could we call this 'v1' of the codebase and not have it in the import path? Or do you have the have the 'v1' there anyway? |
The thing I'm not really sure on is how changing the Additionally, forgot about #540, will want to include that in this PR. |
I see. I have to think about this a bit more, I'll try to do that over the weekend, but feel free to merge to develop for now. Basically, I think there's two things we need to version here:
And everything else should be unversioned if we can get away with it. As I said, I'll look and see if this is actually possible. A quick read of go modules makes me think it's not. Perhaps if they were on different repos. |
@autrilla From what I can tell from my experiments it seems like this might cause only minor breakage for some users. One concern that I had was whether this could require all users using the root@18591ccbf56d:/go/t# go version
go version go1.9.7 linux/amd64
root@18591ccbf56d:/go/t# cat ../src/github.com/ajvb/modules-testing-sops/go.mod
module github.com/ajvb/modules-testing-sops/v2
go 1.13
root@18591ccbf56d:/go/t# cat ../src/github.com/ajvb/modules-testing-sops/anotherfile.go
package modules_testing_sops
import "fmt"
func AnotherExampleFunc(msg, secondMsg string) {
fmt.Println(msg)
fmt.Println(secondMsg)
}
root@18591ccbf56d:/go/t# cat ../src/github.com/ajvb/modules-testing-sops/submodule/example.go
package submodule
import "github.com/ajvb/modules-testing-sops/v2"
func SubmoduleFunc(msg string) {
modules_testing_sops.AnotherExampleFunc(msg, msg)
}
root@18591ccbf56d:/go/t# cat main.go
package main
import "github.com/ajvb/modules-testing-sops/submodule"
func main() {
submodule.SubmoduleFunc("test")
}
root@18591ccbf56d:/go/t# go run main.go
test
test Though the above is seemingly using code with As well, I think where this might cause stuff to break is that people who have sops with a commit pin in their Please feel free to double check me as I still feel very new to go modules, but I think we are in the relative clear for breakage. Lastly, after thinking about it a bit, I think that versioning the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking forward to this! Noticed one thing to check
@ajvb thanks a lot for explaining. I am very surprised things still work for older versions of Go, so since that's the case, I have no objections to merging this whatsoever! |
@autrilla Of course! Same hehe and sounds good. |
06aa53c
to
d917a74
Compare
@@ -10,7 +10,7 @@ all: test vet generate install functional-tests | |||
origin-build: test vet generate install functional-tests-all | |||
|
|||
install: | |||
$(GO) install go.mozilla.org/sops/cmd/sops | |||
$(GO) install go.mozilla.org/sops/v3/cmd/sops |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@carlpett Not changing this was the cause of the addition of the old sops path to go.mod
.
d917a74
to
8c21479
Compare
Upgrade sops to go 1.13, making proper use of go modules internally - https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
fyi @g-k - Until this is merged into master and released,
sops
cannot be imported using go modules in go 1.13Supersedes #531
Relates to Homebrew/homebrew-core#44191