dependencies: Replace square/go-jose.v2 with go-jose/go-jose.v2 #6598
Conversation
…go-jose/go-jose`. Additionally, work on `square/go-jose v2` has stopped. Further work will be done on `go-jose/go-jose v3`. However, there's an important intermediary step needed which is to switch the package author from square to go-jose while maintaining the existing version tag. If for some reason we needed a patch on the v2 branch while v3 was still being worked on, this change would allow us to make progress with one less step. See [upstream go-jose/go-jose](go-jose/go-jose#28) for patch history. Here's how I performed this upgrade ``` grep -rli 'gopkg.in/square/go-jose.v2' 2>&1 | grep -v grep | grep -v '.gocache' | grep -v 'bin/' | grep -v vendor | grep -v '.git' | xargs -i@ sed -i 's|square/go-jose.v2|go-jose/go-jose.v2|g' @ rm go.sum go mod vendor go mod tidy ```
| @@ -77,6 +77,7 @@ require ( | |||
| google.golang.org/genproto v0.0.0-20210602131652-f16073e35f0c // indirect | |||
| gopkg.in/alexcesaro/statsd.v2 v2.0.0 // indirect | |||
| gopkg.in/fsnotify.v1 v1.4.7 // indirect | |||
| gopkg.in/square/go-jose.v2 v2.6.0 // indirect | |||
There was a problem hiding this comment.
Ahaha this has shows us something kinda funny. Why is square/go-jose still showing up in our indirect dependencies? Because the go-jose package has two subpackages (specifically /cipher and /json) which it imports... and the go-jose/go-jose version of the repo hasn't re-written those import statements!
I think this is totally fine -- this PR is still a step in the right direction, and it'll make future version upgrades easier. Just amusing to note.
There was a problem hiding this comment.
I saw that too, but was not sure how you figured out /cipher and /json still come from square/go-jose other than just grepping. I thought it may have been some other package boulder uses is using square/go-jose... which I guess is this case.
There was a problem hiding this comment.
We could fix those statements and then make a v2.6.1 tag. I think I would prefer to do that.
There was a problem hiding this comment.
I figured it out by looking at modules.txt, which still lists
gopkg.in/square/go-jose.v2/cipher
gopkg.in/square/go-jose.v2/json
edit: oops I answered the wrong question. I totally just figured it out by grepping :P I cded into the vendor/ directory, searched for "square/go-jose", and saw that it was files in go-jose that included that string.
Updating the v2 branch to reference itself, tagging 2.6.1, and updating our dependency here is definitely a solution. Personally, I think using your other PR to skip straight to v3.x is the better ("more holistic") solution.
There was a problem hiding this comment.
The go-jose/go-jose v2 branch already completed this work via
When do you think would be an appropriate time to start using v3 instead of using the proposed v2.6.1?
Work on
square/go-jose v2has stopped. Further work will be done ongo-jose/go-jose v3. However, there's an important intermediary step needed which is to switch the package author from square to go-jose while maintaining the existing version tag (v2.6.0used by boulder). If for some reason we needed a patch on the v2 branch while v3 was still being worked on, this change would allow us to make progress with one less step.See upstream go-jose/go-jose for patch history.
Here's how I performed this upgrade