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

[jonasdebeukelaer]

I'd like to +1 that @blkperl, just spent a lot of time trying to figure out how to get the argo downloaded properly without a bunch of errors popping up (it kept fetching the 2.5 incompatible releases)

[alexec]

I think we should document this.

[alexec]

#3369

[cameracker]

hey I know I'm running here very late but I think the problem that you guys ran into was that if you're opting into modules at a version later than major v0 or v1, you must release this as a new major version of the library.
See gofrs/uuid#61

[alexec]

https://donatstudios.com/Go-v2-Modules

[alexec]

Ok. We cannot support Gomodules because awful.

Instead, get the specific tag related:

revision=$(git ls-remote --tags https://github.com/argoproj/argo refs/tags/v2.11.1 | grep "$rx" | sort -d | tail -n1)
go get github.com/argoproj/argo@$revesion

Patch version? E.g. v2.11.1?

rx=^v2\.11\.1$

Minor version? E.g. v2.11

rx=^v2\.11\.[0-9]*$

Major version. E.g. v2

rx=^v2\.[0-9]\.[0-9]*$