0

go list -m -versions gopkg.in/urfave/cli.v1 gives me the following version listing, that has 1.20.0 as the newest version:

gopkg.in/urfave/cli.v1 v1.0.0 v1.1.0 v1.2.0 v1.3.0 v1.3.1 v1.4.0 v1.4.1 v1.5.0 v1.6.0 v1.7.0 v1.7.1 v1.8.0 v1.9.0 v1.10.0 v1.10.1 v1.10.2 v1.11.0 v1.11.1 v1.12.0 v1.13.0 v1.14.0 v1.15.0 v1.16.0 v1.16.1 v1.17.0 v1.17.1 v1.18.0 v1.18.1 v1.19.0 v1.19.1 v1.20.0

However, according gopkg.in, 1.22.4 should be the newest version. 1.22.4 is also the newest release on the package's GitHub repo.

How should I go troubleshooting this problem? Seems like it could be a cache issue.

For background info: the repository originally had dep-based dependency listing (Gopkg.toml), that had version 1.20. I prefer modules, so I initialised go.mod by go mod init $REPO_URL. I later pulled the latest commits from the repo, which had the package version updated to 1.22. I tried re-creating go.mod; it first indicated a problem at that step:

go: converting Gopkg.lock: stat gopkg.in/urfave/cli.v1@v1.22.0: gopkg.in/urfave/cli.v1@v1.22.0: invalid version: go.mod has non-....v1 module path "github.com/urfave/cli" at revision v1.22.0

In the end, I ended up with code that expects version 1.22, but the tools fetch the version 1.20 which isn't forwards compatible, so it doesn't compile.

GolDDranks
  • 3,272
  • 4
  • 22
  • 30

1 Answers1

3

There is nothing you can do to fix it. The package is broken, so the package author/maintainer needs to fix it.

In short, the project has an invalid go.mod file, which was apparently added after v1.20.0 was released--which is why up to that version is available.

The go.mod file refers to "github.com/urfave/cli", but the package is imported as "gopkg.in/urfave/cli.v1". The go.mod file needs to be updated to reflect the proper import path.

As a work-around, it might work to import the package as "github.com/urfave/cli", but this will break many packages that have "sub" packages that refer to the alternate import path. I'd say it's worth a try in this case, though.

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
  • It was worth a try; it worked! So to add: it seems that the package _at_ `gopkg.in/urfave/cli.v1` is, indeed, broken, while the package at `github.com/urfave/cli` is not. I'm not aware if the author is aware of this, and if they intend to maintain `gopkg.in/urfave/cli.v1`. However, it's unclear to me how the problem of "canonical paths" would be resolved here. – GolDDranks Jul 22 '20 at 01:50
  • Perhaps `gopkg.in` was abandoned when they switched to go modules (the main problem it solve is no longer relevant). *shrug* Might be worth opening an issue on their GitHub page. – Jonathan Hall Jul 22 '20 at 06:36