import latest v2.7.0 argo version in go project

[juchaosong]

Summary

How can I import latest argo in go project?

Motivation

Why do you need to know this, any examples or use cases you could include?
when I want import argo v2.7.0 in my project

go get github.com/argoproj/argo@v2.7.0

But I got error

not found: github.com/argoproj/argo@v2.7.0: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

How to fix it?

[alexec]

We had a PR to fix this, #1375 ?

Can you do go get github.com/argoproj/argo?

[juchaosong]

We had a PR to fix this, #1375 ?

Can you do go get github.com/argoproj/argo?

go get github.com/argoproj/argo

But got

github.com/argoproj/argo v2.5.2+incompatible

not v2.7.0

[juchaosong]

Referring to golang/go#35732.
Use

go get github.com/argo/proj/argo@master

It will get latest argo version.
Referring to https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning
It should be

module github.com/argoproj/argo/v2

not https://github.com/argoproj/argo/blob/master/go.mod#L1

[alexec]

Would you like to submit a PR to fix this ?

[alexec]

@tcolgate FYI

[tcolgate]

Yes, my previous PR fixes this, but it's a big change and is very invasive (also has implications for future v3 updates, and people should probably discuss if the related kube CRD resource version should be taken into consideration).
Realistically I'm not going to get to work on this any time soon, but the PR may be enough.

[alexec]

It does't look possible to to migrate to Gomodules using v2 because you must either use "branch" or "subdirectory":

https://stackoverflow.com/questions/53344471/taking-a-repository-to-v2

Both these solutions have downsides that mean we could not use them without making changes that are too time consuming and risky.

Marking as "won't fix".

I'd love to understand why Gomodules makes this impractical - or better still - someone show me I've misunderstood and there's a much easier way.

[blkperl]

@alexec Since the bug is not going to be fixed then the supported installation method becomes using argo@stable or argo@release-<version>? It's not as ideal but it's better than using argo@master. Is this something we could add to the README for users that have argo as a dependency?

Users could add the version number as a comment in the go.mod file to keep track of what version they are on as a workaround. That is likely what my company will end up doing for our projects since v0.0.0-20200528233840-0fff4b21c21c is not useful.

$ go get github.com/argoproj/argo@stable
go: github.com/argoproj/argo stable => v0.0.0-20200528233840-0fff4b21c21c
go: downloading github.com/argoproj/argo v0.0.0-20200528233840-0fff4b21c21c

or

$ go get github.com/argoproj/argo@release-2.8
go: github.com/argoproj/argo release-2.8 => v0.0.0-20200528233840-0fff4b21c21c